El modelamiento UML de campeonatos permite representar visualmente las entidades, relaciones, reglas y comportamientos que forman parte de un torneo. El objetivo es transformar un enunciado del dominio en un modelo comprensible, coherente y útil para el diseño del software.
En un campeonato interesa conocer la fecha del torneo, los encuentros celebrados y el ganador. De cada persona interesa saber sus datos básicos: NIF, nombre completo y fecha de nacimiento. La clase Fecha se modela con tres campos (día, mes y año) de tipo entero.
Qué es UML y por qué resulta útil en un campeonato
UML (Unified Modeling Language) es un lenguaje de modelado visual estandarizado que permite especificar, diseñar y documentar la estructura y el comportamiento de un sistema de software mediante diagramas, sin escribir código.
El Lenguaje unificado de modelado (UML) es un forma estándar de visualizar sistemas complejos, como arquitectura de software o bases de datos, y facilitar la comprensión de sus relaciones, características y comportamientos.
Un diagrama UML es una forma de visualizar sistemas y software utilizando el Lenguaje Unificado de Modelado (UML). Los ingenieros de software crean diagramas UML online para comprender los diseños, la arquitectura del código y la implementación propuesta de sistemas de software complejos. Los diagramas UML también se utilizan para modelar flujos de trabajo y procesos empresariales.
El UML facilita la comprensión de sistemas vastos y complejos al desglosarlos en componentes pequeños e ilustrar cómo están conectados. Al mostrar toda la información necesaria en un único lugar, los equipos pueden resolver problemas de forma más eficaz e identificar lagunas que podrían no haber sido visibles con anterioridad.
En el caso de un campeonato, el diagrama permite identificar las clases principales, separar los datos de cada entidad y hacer visibles reglas como la participación de un jugador en un encuentro, la existencia de dos roles de jugador y la obligación de que el torneo tenga un ganador.
Las categorías de diagramas UML
Existen dos categorías de diagramas UML: estructurales y de comportamiento. Existen 14 subtipos de diagramas dentro de estas dos categorías.
Los diagramas estructurales capturan los aspectos estáticos de un sistema, entre los que se incluyen los atributos y jerarquías. Los diagramas de comportamiento muestran el comportamiento dinámico de un sistema, como por ejemplo los procesos, efectos y cambios que puedan suceder a lo largo del tiempo.
| Categoría | Diagramas | Qué responde |
|---|---|---|
| Estructurales (7) | Clases, Objetos, Componentes, Estructura compuesta, Despliegue, Paquetes, Perfil | Qué piezas tiene el sistema y cómo se relacionan |
| Comportamiento (3) | Casos de uso, Actividades, Máquina de estados | Qué hace el sistema a lo largo del tiempo |
| Comportamiento → Interacción (4) | Secuencia, Comunicación, Tiempos, Global de interacciones | Cómo se intercambian mensajes las piezas |
Los diagramas de interacción se cuentan dentro de los 7 de comportamiento, no aparte.
El diagrama de clases es el recurso principal para modelar la estructura de un campeonato, ya que permite representar clases, atributos, operaciones y relaciones entre entidades.
Cómo extraer las clases del enunciado
El primer paso a realizar consiste en leer detenidamente el enunciado y de él extraer toda la información posible.
Se procederá a identificar las clases a partir del enunciado y de encapsular en ellas la información relacionada. Este paso se realizará considerando de forma aislada unas clases de otras.
A partir de la información del campeonato pueden identificarse las siguientes clases:
- Torneo, que representa el campeonato.
- Persona, que contiene los datos básicos de una persona.
- Jugador, que representa a la persona que participa en los encuentros.
- Fecha, que modela una fecha mediante día, mes y año.
- Nif, que identifica de forma unívoca a una persona.
- Encuentro, que representa un enfrentamiento entre dos jugadores.
- Marcador, que encapsula el resultado de una partida.
Estas clases permiten separar la información general del torneo, los datos personales, la participación deportiva y los resultados.
La estructura de una clase UML
Los diagramas de clases se resumen en dos partes: clases y la relación entre clases.
La definición de una clase se muestra en la siguiente figura. Consta principalmente de tres partes, que son el nombre de la clase. los atributos de la clase, el método de la clase corresponde al contenido de las tres particiones en la figura.
Nombre, atributos y métodos
- Nombre de la clase: el cuadro rectangular superior de la imagen es el nombre de la clase. Si la fuente está en cursiva, se representa como una clase abstracta.
- Atributos de clase: el área debajo del nombre de la clase.
- Métodos de clase: la parte inferior de la figura.
En el modelo del campeonato, la clase Fecha puede contener los atributos día, mes y año, todos ellos de tipo entero. La clase Persona puede contener NIF, nombre completo y fecha de nacimiento. La clase Marcador encapsula el resultado de una partida mediante dos números de tipo entero.
El primer número corresponde a los puntos de primer jugador y el segundo número a los puntos del segundo jugador.
Visibilidad y notación de atributos
Los símbolos "+", "-" y "#" delante de los atributos y métodos indican los niveles de acceso.
- +: público, público, visible para todas las clases.
- -: privado, privado, solo disponible para la clase misma.
- #: protegido, protegido, visible para los descendientes de esta clase.
- ~: paquete, paquete, solo visible para otras clases declaradas en el mismo paquete.
- =: indica el valor predeterminado.
- Subrayado: estático.
- Cursiva: abstracto.
Antes de los dos puntos está el nombre del método/nombre de la variable (que se distingue por la presencia o ausencia de paréntesis), y después de los dos puntos está el parámetro de retorno/tipo de variable (que se distingue por la presencia o ausencia de paréntesis).
significa que el método devuelve void (algunas personas también usan: void para indicar retorno void).
Relaciones entre las clases del campeonato
En esta fase se va a evaluar qué clases tienen que ver con qué otras, es decir sus relaciones.
Las relaciones entre clases incluyen principalmente 6 relaciones: generalización (herencia), dependencia, asociación, agregación, combinación e implementación.
Generalización o herencia
La relación de generalización es una relación de herencia. La subclase hereda todos los comportamientos y atributos de la clase principal. La subclase puede agregar nuevas funciones o reescribir las funciones de la clase principal.
En el campeonato, Jugador puede modelarse como una especialización de Persona. Persona contiene los datos comunes, mientras que Jugador incorpora las características necesarias para participar en encuentros.
Método de representación: triángulo hueco + línea continua, flecha que apunta a la clase principal.
Obsérvese que los atributos que hereda la clase Jugador, que es la clase especializada, no se representan.
Dependencia
Una relación de dependencia indica que una clase usa (depende de) los servicios o la información de otra clase. Existe una dependencia entre dos clases cuando los cambios en una clase afectan a otra clase.
En términos generales, las dependencias son siempre unidireccionales y no debería haber dependencias bidireccionales.
Método de representación: corchetes angulares + línea de puntos.
Asociación
Una asociación es una relación de propiedad que hace que una clase conozca las propiedades y métodos de otra clase. Encarna una fuerte relación de dependencia de diferentes tipos, como yo y mis amigos.
Esta relación es más fuerte que la dependencia. No hay contingencia en las relaciones de dependencia y la relación no es temporal, sino que generalmente es a largo plazo.
Las relaciones de asociación se dividen en asociaciones unidireccionales o asociaciones bidireccionales, y también pueden tener multiplicidad (uno a muchos).
Las asociaciones bidireccionales pueden tener dos flechas o ninguna flecha, y las asociaciones unidireccionales pueden tener una flecha.
Método de representación: corchetes angulares + línea continua, la flecha apunta al propietario.
En el campeonato, una asociación puede vincular Persona con Fecha mediante el atributo fechaNac. También puede vincular Encuentro con Jugador para representar la participación de los jugadores.
Agregación
La relación de agregación es un tipo de relación de asociación, que representa una relación de "propiedad" "débil". Es la relación entre el todo y la parte, y la parte puede existir de forma independiente sin el todo.
El siguiente paso consiste en considerar qué clase es la parte [PARTE] y qué clase es la parte [TODO]. Dicho de otro modo quién contiene a quién.
El siguiente paso consiste en determinar si la relación de asociación entre las clases es de agregación o de composición.
Método de representación: diamante hueco + línea continua, el diamante apunta al conjunto.
En un campeonato, un torneo puede agrupar encuentros y jugadores, mientras que esas entidades pueden considerarse existentes independientemente del torneo según las reglas del modelo.
Composición
La relación de combinación es también un tipo de relación de asociación. Es una relación más fuerte que la relación de agregación.
Es la relación entre el todo y el individuo, pero el individuo no puede existir solo sin el todo.
Requiere que el objeto que representa el todo en una relación de agregación normal sea responsable del ciclo de vida del objeto que representa la parte.
Para que la relación sea de composición es condición necesaria que la cardinalidad de la parte [TODO] sea 1.
Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de la relación.
Método de representación: diamante sólido + línea continua.
La relación entre Persona y Nif puede interpretarse como composición cuando el NIF no puede utilizarse sin la persona a la que identifica.
Implementación
La relación de implementación es una relación entre una clase y una interfaz, lo que indica que la clase es la realización de todas las características y comportamientos de la interfaz.
Método de representación: triángulo hueco + línea de puntos.
Sin embargo, ¿Cómo reconocer a un jugador de tenis de mesa sin verlo jugar? La respuesta viene a través de los interfaces.
Un interfaz es como un título que faculta a su poseedor en una determinada habilidad.
Asociaciones, navegabilidad y multiplicidad
Una vez se han resuelto las relaciones de herencia le toca el turno a las relaciones de asociación. Se procederá siempre abordando primero las triviales o más simples y continuando por las demás.
Esta asociación es trivial. Así considerado, el atributo fechaNac de la clase Persona pasa a ser el rol de la relación que vincula a ambas clases.
Ahora hay que abordar la navegabilidad tratando de ver si desde una clase se puede ir a la otra.
Sin embargo, la clase Persona tiene una referencia a la clase Fecha por lo que sí es viable la navegabilidad desde la clase Persona hacia la clase Fecha.
El siguiente paso es abordar las cardinalidades o multiplicidades, es decir el número de instancias de cada clase que intervienen en la relación.
Obsérvese que cuando la cardinalidad mínima y máxima coinciden sólo se representa una de ellas.
Las multiplicidades permiten expresar restricciones como:
- Una persona puede tener una fecha de nacimiento.
- Un encuentro debe tener dos participantes.
- El ganador de un encuentro debe ser uno de los dos participantes.
- Un torneo debe tener siempre un ganador.
Relación entre Persona, Fecha y Nif
El análisis de la relación entre estas dos clases determina que cada objeto de la clase Nif está unívocamente unido a un solo objeto de la clase Persona, y viceversa, por lo que la cardinalidad en ambos lados es la unidad.
Además semánticamente si desaparece la parte [TODO], el objeto de la clase Persona, la existencia de la parte [PARTE], el objeto de la clase Nif, ya no puede ser utilizado y debería desaparecer también.
Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de la relación.
Relación entre Encuentro y Jugador
La relación entre la clase Encuentro y la clase Jugador es muy interesante.
Respecto a las cardinalidades, obsérvese que todos los jugadores que participen en un encuentro tienen que hacerlo en alguno de dos roles: jugador1 o jugador2 pero no en los dos al mismo tiempo.
Asimismo, aquellos jugadores que participen en varios encuentros pueden ostentar diferentes roles en cada uno de ellos, o no.
Finalmente, el ganador de un encuentro debe ser uno de los dos participantes del mismo.
Esta relación puede representarse mediante roles diferenciados, como jugador1, jugador2 y ganador, evitando ambigüedades en el modelo.
Reglas del campeonato y modelamiento de partidas
En el contexto del supuesto de este ejercicio, en un encuentro se celebran tres partidas, el primer jugador que llegue a 21 puntos gana la partida.
El jugador que gane más partidas de un encuentro gana el encuentro.
Obsérvese que no puede haber empate ni en las partidas ni en el encuentro.
La clase Marcador encapsula el resultado de una partida mediante dos números de tipo entero, el primer número corresponde a los puntos de primer jugador y el segundo número a los puntos del segundo jugador.
El modelo debe vincular cada marcador con la partida correspondiente y cada partida con su encuentro. De esta manera, el resultado de una partida no queda separado de los jugadores que la disputan ni del encuentro en el que se celebra.
El objetivo de un torneo es tener siempre un ganador.
| Elemento | Regla |
|---|---|
| Encuentro | En un encuentro se celebran tres partidas |
| Partida | El primer jugador que llegue a 21 puntos gana la partida |
| Encuentro | El jugador que gane más partidas de un encuentro gana el encuentro |
| Empate | No puede haber empate ni en las partidas ni en el encuentro |
| Torneo | El objetivo de un torneo es tener siempre un ganador |
Los diagramas UML aplicables al campeonato
Diagrama de clases
El diagrama de clases tiene como objetivo principal reflejar la estructura (atributos, operaciones) de las clases y la relación entre clases.
Describe la estructura del sistema de software y es un método de modelado estático.
Los diagramas de clases se utilizan para describir conceptos significativos en el sistema, incluidos conceptos específicos, conceptos abstractos, conceptos de implementación, etc.
Son abstracciones de cosas del mundo real.
El objetivo principal de los diagramas de clases es modelar el vocabulario del sistema, modelar colaboraciones simples y modelar el esquema lógico de la base de datos.
Para el campeonato, el diagrama de clases es el modelo central: contiene Torneo, Persona, Jugador, Fecha, Nif, Encuentro y Marcador, junto con sus relaciones y multiplicidades.
Diagrama de objetos
Una instantánea del diagrama de clases con datos reales dentro.
En vez de la clase Producto, ves producto_4471: Producto con precio = 49,90.
Sirve para validar que un modelo abstracto aguanta un caso concreto.
Un diagrama de objetos en UML puede parecerse a un diagrama de clases porque se centra en los atributos de un diagrama de clases y cómo esos objetos se relacionan entre sí.
Los diagramas de objeto representan instancias específicas de estilos de clase más abstractos.
En un campeonato, un diagrama de objetos podría mostrar un torneo concreto, una fecha determinada, dos jugadores específicos, un encuentro y sus marcadores.
Diagrama de actividades
Un flujo de control con nodos de decisión, bifurcaciones y barras de sincronización para el paralelismo.
Es prácticamente un diagrama de flujo con semántica formal.
Es el mejor de los catorce para documentar procesos de negocio y flujos donde varias cosas ocurren en paralelo.
Los diagramas UML de actividad representan procesos paso a paso con un inicio y un final claros.
Para el campeonato puede representar el proceso de inscripción, creación de encuentros, celebración de partidas, registro del marcador y determinación del ganador.
Diagrama de máquina de estados
Modela los estados por los que pasa un objeto y qué eventos provocan cada transición.
Estado inicial, estados intermedios, transiciones con guardas, estado final.
Este es el diagrama infravalorado del conjunto.
Cualquier entidad de negocio con ciclo de vida -un pedido que va de creado a pagado, preparando, enviado y entregado, con ramas hacia cancelado y devuelto- gana más de un diagrama de estados que de tres reuniones.
Y detecta transiciones imposibles que nadie había considerado, como pasar de devuelto a enviado.
En el campeonato, un encuentro puede modelarse mediante estados como creado, en curso, finalizado y anulado, mientras que un jugador puede tener estados relacionados con su participación.
Diagrama de secuencia
El campeón absoluto de uso real.
Cualquier persona que trabaje en desarrollo backend acaba dibujando diagramas de secuencia aunque nunca haya estudiado UML formalmente.
Los diagramas de secuencia UML muestran cómo los distintos objetos se relacionan e interactúan entre sí en un sistema.
Esta herramienta ayuda a los desarrolladores a comprender cómo, por qué y en qué orden se producen estas interacciones.
En el campeonato puede mostrar la secuencia en la que el sistema registra a los jugadores, crea un encuentro, anota los puntos, determina al ganador de cada partida y proclama al ganador del encuentro.
Diagrama de comunicación
La misma información que el de secuencia, pero organizada alrededor de las relaciones entre objetos en vez de sobre un eje temporal.
Los mensajes van numerados.
Sirve cuando lo que te interesa ver es la topología de conexiones y no el orden.
Los diagramas de comunicación en UML son similares a los diagramas de secuencia, pero su enfoque principal está en los mensajes que se transmiten entre objetos más que en la secuencia temporal.
Anteriormente conocidos como diagramas de colaboración, estos diagramas de comportamiento representan cómo interactúan los objetos a través de mensajes dentro del diseño arquitectónico de un sistema.
Diagrama de tiempos
Representa cambios de estado sobre un eje temporal explícito, con duraciones y restricciones de tiempo.
Su terreno son los sistemas de tiempo real, el software embebido y los protocolos de comunicación.
Los diagramas UML de cronometraje se usan para representar cómo se relacionan los objetos cuando el enfoque principal es el tiempo.
En un sistema de gestión de campeonatos, puede ser útil si se requiere controlar tiempos concretos de una partida, pausas, rondas o límites temporales.
Diagrama global de interacciones
Combina varios diagramas de interacción en un flujo de nivel superior, usando la notación de actividades para encadenarlos.
Es útil en sistemas grandes donde hace falta una vista de conjunto de escenarios.
Los diagramas UML de información general sobre interacciones son diagramas de actividad construidos a partir de múltiples modelos más pequeños (normalmente, diagramas de tiempo, diagramas de secuencia y diagramas de comunicación).
En un campeonato grande puede conectar los flujos de inscripción, sorteo, programación, celebración de encuentros, clasificación y proclamación del ganador.
Proceso paso a paso para construir el diagrama de clases
1. Leer y descomponer el enunciado
El primer paso a realizar consiste en leer detenidamente el enunciado y de él extraer toda la información posible.
Conviene separar los sustantivos, que pueden convertirse en clases, de las características, que pueden convertirse en atributos, y de las acciones, que pueden convertirse en operaciones.
2. Identificar las clases
Se procederá a identificar las clases a partir del enunciado y de encapsular en ellas la información relacionada.
En este caso, las clases principales son Torneo, Persona, Jugador, Fecha, Nif, Encuentro y Marcador.
3. Definir los atributos
La clase Fecha se modela con tres campos (día, mes y año) de tipo entero.
De cada persona interesa saber sus datos básicos: NIF, nombre completo y fecha de nacimiento.
La clase Marcador encapsula el resultado de una partida mediante dos números de tipo entero.
4. Resolver la herencia
Una vez se han resuelto las relaciones de herencia le toca el turno a las relaciones de asociación.
Obsérvese que los atributos que hereda la clase Jugador, que es la clase especializada, no se representan.
5. Resolver las asociaciones simples
Se procederá siempre abordando primero las triviales o más simples y continuando por las demás.
Así considerado, el atributo fechaNac de la clase Persona pasa a ser el rol de la relación que vincula a ambas clases.
6. Determinar la navegabilidad
Ahora hay que abordar la navegabilidad tratando de ver si desde una clase se puede ir a la otra.
Sin embargo, la clase Persona tiene una referencia a la clase Fecha por lo que sí es viable la navegabilidad desde la clase Persona hacia la clase Fecha.
7. Establecer cardinalidades
El siguiente paso es abordar las cardinalidades o multiplicidades, es decir el número de instancias de cada clase que intervienen en la relación.
Obsérvese que cuando la cardinalidad mínima y máxima coinciden sólo se representa una de ellas.
En Encuentro y Jugador deben expresarse los dos roles de jugador: jugador1 y jugador2. El ganador debe corresponder a uno de los participantes.
8. Determinar todo y parte
El siguiente paso consiste en considerar qué clase es la parte [PARTE] y qué clase es la parte [TODO].
Dicho de otro modo quién contiene a quién.
9. Elegir agregación o composición
El siguiente paso consiste en determinar si la relación de asociación entre las clases es de agregación o de composición.
Para que la relación sea de composición es condición necesaria que la cardinalidad de la parte [TODO] sea 1.
Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de la relación.
Y este es básicamente el proceso a seguir para analizar las relaciones de asociación entre las clases de un diagrama de clases UML.
10. Comprobar las reglas del dominio
Llegados a este punto todas las relaciones entre clases están establecidas.
Esta decisión no es una vuelta atrás ni mucho menos.
El modelo debe comprobar que un encuentro tenga dos participantes, que los roles no se solapen, que el ganador pertenezca al encuentro y que el torneo tenga siempre un ganador.
Ejemplo de relaciones entre clases
Para ayudarlo a comprender mejor las seis relaciones entre clases, a continuación se utilizan ejemplos para ayudarlo a aprender y digerir.
Ejemplo de asociación
La relación entre estudiantes y cédulas de identidad es de "asociación", representada por una línea continua con una flecha puntiaguda.
En el campeonato, la asociación entre Persona y Fecha permite modelar la fecha de nacimiento mediante el rol fechaNac.
Ejemplo de agregación
Existe una relación de "agregación" entre estudiantes y clases, representada por una línea continua con una flecha de diamante hueca.
En el modelo del torneo, una relación de agregación puede utilizarse cuando el torneo agrupa encuentros, pero los encuentros pueden conservar una existencia independiente.
Ejemplo de composición
Existe una relación de "combinación" entre el automóvil, el motor y los neumáticos, que está representada por la línea sólida de la flecha de diamante sólido.
La relación entre una empresa y un departamento es un todo y una parte. Sin empresa no habría departamento.
En el campeonato, la composición puede emplearse cuando la desaparición del todo implique necesariamente la desaparición de la parte.
Ejemplo de dependencia
Los estudiantes necesitan usar bicicletas para ir a la escuela, y existe una relación de "dependencia" con las bicicletas, que se representa mediante una línea de puntos con una flecha.
En el sistema del campeonato, una clase puede depender de otra cuando utiliza sus servicios o información sin mantener una relación estructural permanente.
Ejemplo de implementación
Existe una relación de "realización" entre automóviles, automóviles y bicicletas, que está representada por una línea de puntos con una flecha hueca.
En el modelo deportivo, un interfaz puede representar una habilidad o capacidad que una clase Jugador debe implementar.
Herramientas para dibujar el modelo UML
Para aprovechar el UML al máximo, selecciona una herramienta que simplifique lo máximo posible la creación, uso compartido y edición de diagramas UML de apariencia profesional.
| Herramienta | Tipo | Coste | Para qué encaja |
|---|---|---|---|
| Mermaid | Diagrams-as-code | Gratis, open source | Diagramas dentro de Markdown; renderiza nativo en GitHub, GitLab y Notion |
| PlantUML | Diagrams-as-code | Gratis, open source | Cobertura UML más completa; el estándar para modelado C4 serio |
| draw.io / diagrams.net | GUI | Gratis | Diagramas rápidos, colaborativos, sin instalar nada |
| Visual Paradigm | GUI profesional | Freemium | Modelado formal, ingeniería directa e inversa de código |
| StarUML | GUI de escritorio | Licencia de pago | Modelado completo con generación de código |
| Enterprise Architect | GUI empresarial | Licencia de pago | Entornos regulados, trazabilidad de requisitos |
| Lucidchart | GUI colaborativa | Freemium | Equipos mixtos con perfiles no técnicos |
ProcessOn admite el dibujo de diagramas de flujo, mapas mentales, diagramas UML, diagramas de arquitectura y otros gráficos.
El método para utilizar ProcessOn para dibujar diagramas de clases UML es muy simple, siempre que domine los puntos de conocimiento del dibujo de diagramas de clases y los estudie y comprenda.
El creador de diagramas UML de Canva te permite trabajar con plantillas atractivas y herramientas, fáciles de usar, que potenciarán tus sesiones de planificación de progresos o de lluvia de ideas para nuevas funciones de aplicaciones.
- Usa plantillas diseñadas por profesionales para acelerar tu flujo de trabajo.
- Visualiza tus datos más fácilmente, sin tener que aprender a usar software complejos.
- Publica, comparte y descarga tu diagrama en alta resolución.
- Incrusta tu diagrama UML en presentaciones, informes y mucho más sin complicaciones.
- Aprovecha nuestras herramientas de arrastrar y soltar, pensadas para personas sin experiencia en diseño.
Pasos para crear el diagrama en una herramienta visual
- Regístrese e inicie sesión en ProcessOn y cree un nuevo gráfico UML.
- Seleccione el logotipo de la clase en la barra de herramientas de la izquierda, arrástrelo al área de edición derecha y escriba el nombre de la clase, los atributos y los métodos.
- Marque las flechas y líneas según la relación entre las clases.
Las conexiones entre cada icono de ProcessOn son flechas sólidas de forma predeterminada.
Puede ajustar el estilo de conexión, el tipo de conexión, el color de la conexión, la dirección de la flecha y el estilo de la flecha en la barra de herramientas superior según sea necesario.
Si desea que sus imágenes sean más hermosas, puede rellenar texto, íconos, líneas, etc. con diferentes colores y hacer que los mismos íconos tengan el mismo tamaño posible.
Diagramas como código
Diagrams-as-code es un formato, no una notación.
Mermaid permite crear diagramas dentro de Markdown y renderiza nativo en GitHub, GitLab y Notion.
PlantUML ofrece una cobertura UML más completa.
Reescribe esos diagramas en Mermaid o PlantUML y súbelos a un repositorio.
Es la diferencia entre saber UML y usar UML.
Buenas prácticas para el modelamiento UML de campeonatos
Empieza por el objetivo del diagrama
Un diagrama UML tiene un propósito específico, por eso existen tantos tipos diferentes.
Deberías sentarte con tu equipo de desarrollo y entender por qué estáis creando el diagrama UML.
Esto os ayudará a elegir el tipo de diagrama más óptimo, lo que, a su vez, ayudará a conseguir los mejores resultados posibles.
Usa el nivel de detalle adecuado
Los diagramas UML pueden parecer complicados, pero el proceso para crear uno no tiene por qué serlo.
Algunas etapas o procesos pueden no ser adecuados para tu público, así que considera cómo enmarcas el contenido de tu diagrama UML.
Mantén tus etiquetas y descripciones claras y concisas.
Después, ordena todos tus elementos sin superponerlos para que se vean claramente las jerarquías y las relaciones.
Valida el modelo con casos concretos
Sirve para validar que un modelo abstracto aguanta un caso concreto.
Es especialmente útil cuando el equipo discute si una relación debería ser 1:N o N:M y nadie se pone de acuerdo: pintas tres objetos reales y la discusión se acaba sola.
Documenta únicamente lo que pueda mantenerse
Y el consejo menos popular: no dibujes lo que no vas a mantener.
Un diagrama desactualizado hace más daño que la ausencia de diagrama, porque la gente lo lee y toma decisiones con información falsa.
Si no vas a actualizarlo, no lo hagas.
Colabora con el equipo
El propósito principal de un diagrama UML es aumentar la comprensión de un equipo a través de la visualización.
Sin embargo, visualizar no es la única forma de mejorar la comprensión.
También puedes compartir tus diagramas UML con tu equipo para promover la colaboración y asegurarte de que todo el mundo está en la misma página.
Esto da a todos los miembros del equipo la oportunidad de contribuir, aumentando así la colaboración.
Tu equipo puede trabajar simultáneamente para generar un diagrama a tiempo para el próximo lanzamiento de tu aplicación o el ciclo de un nuevo producto.
Colabora en tiempo real compartiendo un enlace a tu diseño.
UML Tutorial: Diagrama de Clases desde cero
Cómo aprender UML con este ejemplo
No necesitas saber programar para empezar, aunque ayuda mucho tener nociones.
- Primero, la notación básica. Clases, relaciones y multiplicidad. Distinguir herencia de composición y composición de agregación. Son dos tardes.
- Segundo, dibuja un sistema que conozcas. No un ejemplo de libro. Coge una aplicación que uses a diario y modela su modelo de dominio en un diagrama de clases.
- Tercero, secuencia y estados. Con el mismo sistema del punto anterior, dibuja un flujo completo en diagrama de secuencia y el ciclo de vida de su entidad principal en máquina de estados.
- Cuarto, pásalo a código. Reescribe esos diagramas en Mermaid o PlantUML y súbelos a un repositorio.
Si puede leer y comprender rápidamente el caso anterior, significa que básicamente ha entendido el diagrama de clases.
Si combina más código y el diagrama de clases correspondiente para consolidarlo, no se confundirá cuando vea el diagrama de clases en el futuro.
tags: #modelamiento #de #uml #campeonatos