Métricas de Calidad de Diseño: Alta Cohesión y Bajo Acoplamiento

📌 En síntesis: Evaluación objetiva del código: principios de diseño limpio, métricas de acoplamiento eferente/aferente, cohesión de métodos y refactorización.

Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.

En el proceso de , comprender cómo se comporta un sistema resulta tan importante como conocer su estructura. Mientras los diagramas estructurales (como los de clases u objetos) muestran la organización estática de un sistema, los diagramas de comportamiento UML representan la dinámica, es decir, cómo los objetos colaboran, interactúan y responden a estímulos en tiempo de ejecución. El Lenguaje Uniﬁcado de Modelado (UML) proporciona un conjunto de herramientas gráﬁcas que permiten visualizar y analizar tanto la arquitectura como el funcionamiento interno de una aplicación. En esta clase abordaremos los diagramas que modelan el comportamiento del sistema, los cuales permiten comprender la lógica funcional, los ﬂujos de control y las interacciones entre clases y objetos en tiempo real. Para contextualizar estos conceptos, trabajaremos con un caso práctico: el desarrollo del videojuego Frogger Multiplayer, una adaptación moderna del clásico juego donde varios jugadores compiten simultáneamente para guiar sus ranas a través de un entorno lleno de obstáculos. Este escenario nos permitirá comprender cómo los objetos (jugadores, autos, troncos, ranas, temporizador, etc.) se comunican e interactúan dentro de un sistema concurrente.

🚀 Introducción

⚙️ Comportamiento de un sistema

El comportamiento de un sistema representa el conjunto de acciones, reacciones y respuestas que ocurren dentro de una aplicación ante un conjunto de estímulos o eventos. En otras palabras, describe cómo se comporta el sistema frente a entradas especíﬁcas, mostrando el ﬂujo de control, las decisiones, los estados y las interacciones entre componentes. En el caso de Frogger Multiplayer, el comportamiento del sistema incluye:

Registrar nuevos jugadores.
Iniciar una partida multijugador.
Detectar colisiones entre la rana y los obstáculos.
Calcular puntajes y determinar ganadores.
Coordinar los movimientos simultáneos de los jugadores. Estos comportamientos se modelan mediante diagramas de comportamiento UML, que ayudan a visualizar la secuencia de acciones y la cooperación entre objetos durante la ejecución del sistema.

🧩 Comportamiento de un objeto y su relación con otros objetos

Cada objeto en un sistema orientado a objetos posee un estado, un conjunto de atributos y un comportamiento deﬁnido por sus métodos. El comportamiento de un objeto describe cómo este responde a los mensajes o métodos que recibe de otros objetos. Registrar nuevos jugadores Inicio Iniciar partida multijugador Detección de colisiones Calcular puntajes Determinar ganadores Coordinar movimientos de jugadores Si No Diagrama 1. Diagrama general del comportamiento del sistema Frogger Multiplayer (visión macro del ﬂujo de juego) Fuente: ChatGPT (2023)

En Frogger Multiplayer, por ejemplo:

El objeto Rana puede ejecutar acciones como moverse(), saltar() o colisionar().
El objeto Auto ejecuta avanzar() y detectarColisión().
El objeto Partida coordina la interacción entre todos los jugadores y los elementos del escenario. El comportamiento de cada objeto está determinado por: 1. Su estado interno (atributos). 2. Los eventos que recibe (mensajes o invocaciones). 3. Las reglas del sistema que determinan su reacción. De esta forma, los objetos no actúan de forma aislada, sino en colaboración, enviándose mensajes que activan métodos y provocan cambios de estado. Diagrama 2. Diagrama de comunicación entre objetos (Rana, Auto, Partida, Temporizador) Fuente: ChatGPT (2023) Rana - Moverse() - Saltar() - Colisionar() Auto - Avanzar() - DetectarColision() Partida

A nivel de diseño, las clases deﬁnen los comportamientos posibles de los objetos que instancian. Mientras un objeto es una instancia concreta, la clase es su modelo abstracto. El comportamiento de una clase está determinado por:

Los métodos que implementa (sus operaciones).
Las relaciones que mantiene con otras clases (herencia, asociación o composición).
Su responsabilidad dentro del sistema. En Frogger Multiplayer:
La clase Jugador hereda de Usuario, implementando comportamientos adicionales como moverRana() o actualizarPuntaje().
La clase Partida coordina las acciones simultáneas de los jugadores.
La clase Escenario mantiene las referencias a todos los objetos interactivos del juego. Cada clase, por tanto, deﬁne un contrato de interacción, estableciendo qué servicios ofrece a las demás clases del sistema.

🧩 Comportamiento de una clase y su relación con

🧩 otras clases

El contrato de clase representa el acuerdo formal que una clase establece con el resto del sistema respecto a qué servicios ofrece, bajo qué condiciones y qué comportamientos garantiza al ser utilizada. Este concepto, propuesto por Bertrand Meyer (1988) en su metodología Design by Contract, es esencial en la programación orientada a objetos (POO), ya que asegura la coherencia y robustez del sistema. Un contrato de clase deﬁne tres elementos clave:

Invariantes: condiciones que deben cumplirse en todo momento para la clase (por ejemplo, que una posición no sea negativa o que un saldo no sea menor a cero).

🧩 El contrato de clase

Diagrama 3. Diagrama de clases mostrando relaciones y

responsabilidades en Frogger Multiplayer Fuente: ChatGPT (2023) Jugador + nombre: String + puntuación: int + listo: boolean + unirPartida() + iniciarJuego() Actor + mover() Rana + moverArriba + moverAbajo + moverIzquierda + moverDerecha Automóvil Tronco PartidaMultijugador + jugadores: Jugador() + numRanasVivas: int + agregarJugador() + removerJugador() + comenzar() + ﬁnDelJuego() PartidaMultijugador + jugadores: Jugador() + numRanasVivas: int + agregarJugador() + removerJugador() + comenzar() + ﬁnDelJuego() 0…*

Precondiciones: requisitos que deben cumplirse antes de ejecutar un método.
Poscondiciones: condiciones que deben cumplirse después de la ejecución del método. Relación con los métodos, asociaciones y casos de uso El contrato de clase se maniﬁesta en los métodos, los cuales expresan las operaciones comprometidas en dicho contrato. Estos métodos surgen a partir de los casos de uso, que deﬁnen las interacciones entre los actores y el sistema. Cada caso de uso genera una o más operaciones que luego se traducen en métodos dentro de las clases asociadas. De esta manera: 1. Los casos de uso determinan las responsabilidades del sistema. 2. Esas responsabilidades se asignan a las clases pertinentes. 3. Cada clase declara métodos que formalizan su contrato de colaboración con otras partes del sistema. 4. Dichos métodos se reﬂejan en las asociaciones entre clases (por ejemplo, en los diagramas de clases y de secuencia), garantizando la trazabilidad entre requerimientos, diseño y comportamiento. Ejemplo aplicado al caso Frogger Multiplayer
Invariante: la posición de la rana siempre debe estar dentro de los límites del tablero.
Precondición: la rana solo puede saltar si la partida está en curso y no está en pausa.
Poscondición: la posición se actualiza correctamente tras saltar y se veriﬁca si ha alcanzado la meta. Este contrato no solo formaliza el comportamiento esperado de la clase Rana,

sino que también asegura la comunicación coherente entre objetos, permitiendo detectar inconsistencias desde las etapas de diseño. Representación en UML y conexión con los diagramas El contrato de clase se representa y valida a través de diagramas UML de comportamiento (como los de actividades y secuencia) y diagramas estructurales (como el de clases).

En los diagramas de actividades, se pueden observar las condiciones que activan o restringen la ejecución de métodos, incorporando símbolos de bifurcación y actividades concurrentes, lo que reﬂeja procesos paralelos dentro del sistema (ver Figura 5).
En los diagramas de secuencia, cada caso de uso debe tener su propio diagrama, ya que cada uno representa un ﬂujo especíﬁco de envío y recepción de mensajes entre los objetos participantes.
Estos diagramas se complementan con los de comunicación, que destacan las relaciones y colaboraciones derivadas del contrato de clase. Diagrama 4. Ejemplo de contrato de clase aplicado y su relación con actividades concurrentes Fuente: Booch, Rumbaugh y Jacobson (2006)

En síntesis, el contrato de clase:

Asegura la coherencia entre los casos de uso, los métodos y las interacciones entre objetos.
Facilita la veriﬁcación de condiciones previas y posteriores al ejecutar operaciones.
Refuerza el diseño dirigido por responsabilidades, promoviendo sistemas más mantenibles y veriﬁcables. Los diagramas de comportamiento UML se utilizan para representar cómo los elementos del sistema interactúan a lo largo del tiempo o cómo ﬂuyen las acciones dentro del sistema. En esta clase analizaremos tres de los más importantes: 1. Diagrama de actividades 2. Diagrama de secuencia 3. Diagrama de comunicación (colaboración) 5.1. Diagrama de actividades El diagrama de actividades muestra el ﬂujo de trabajo o proceso lógico dentro de un sistema o una parte de él. Es útil para visualizar decisiones, ramiﬁcaciones y concurrencia de procesos. En Frogger Multiplayer, un diagrama de actividades podría representar el ﬂujo completo de una partida: desde que los jugadores se conectan, hasta que ﬁnaliza el juego y se calcula el ganador.

📐 Diagramas UML de comportamiento

Elementos principales:

Nodos de acción: representan tareas o acciones realizadas en el proceso. Se muestran como rectángulos con bordes redondeados.
Flujos de control: indican la dirección del ﬂujo entre actividades. Se representan como ﬂechas que conectan las actividades.
Decisiones: puntos donde se toma una decisión que afecta el ﬂujo. Se representan como rombos, con diferentes caminos saliendo de ellos según las condiciones.
Inicio y ﬁn: se indican mediante círculos. El círculo lleno representa el inicio, mientras que el círculo con un borde representa el ﬁn del ﬂujo.
Forks y Joins: se utilizan para dividir y unir ﬂujos de actividades. Un fork es un símbolo de barra que indica que un ﬂujo se divide en múltiples ﬂujos paralelos, y un join combina ﬂujos paralelos en un único ﬂujo.
Swimlanes: divisiones en el diagrama que representan diferentes actores, roles o sistemas que participan en el proceso. Ayudan a clariﬁcar quién realiza cada actividad. Diagrama 5. Diagrama de actividades del ﬂujo de una partida multijugador Fuente: ChatGPT (2023) Analizar tiempo y estado del juego Iniciar partida Se han unido n Si No Se han unido n jugadores Esperar acciones de jugadores Fin de la partida Mostrar resultados Mostrar resultados Si No

5.2. Diagrama de secuencia El diagrama de secuencia muestra cómo los objetos se comunican entre sí mediante mensajes ordenados en el tiempo. Se utiliza para analizar escenarios especíﬁcos del sistema. En Frogger Multiplayer, este diagrama puede modelar la secuencia de mensajes cuando una rana colisiona con un auto o cuando un jugador alcanza la meta. Elementos principales:

Objetos: representan las instancias de las clases involucradas en la interacción. Se muestran como rectángulos en la parte superior del diagrama, con el nombre del objeto y, a menudo, el tipo.
Líneas de Vida: líneas verticales que se extienden hacia abajo desde cada objeto, representando la existencia del objeto a lo largo del tiempo.
Mensajes: ﬂechas que conectan las líneas de vida de los objetos. Indican la comunicación entre ellos y pueden incluir el nombre del mensaje, parámetros y el tipo de mensaje (sincrónico o asincrónico).
Activaciones: rectángulos en la línea de vida de un objeto que representan el período durante el cual el objeto está activo o procesando un mensaje.
Destrucción: un símbolo de “X” en la línea de vida de un objeto que indica que el objeto ha sido destruido o ﬁnalizado.
Notas: comentarios o aclaraciones que proporcionan información adicional sobre el diagrama.
Condiciones y bucles: elementos opcionales que se pueden incluir para indicar condiciones o repeticiones en la secuencia de mensajes

5.3. Diagrama de comunicación (colaboración) El diagrama de comunicación (anteriormente llamado de colaboración) representa cómo los objetos se relacionan e intercambian mensajes en un contexto especíﬁco, enfatizando las relaciones más que el tiempo. En Frogger Multiplayer, este diagrama puede mostrar cómo la clase Partida coordina la comunicación entre Jugador, Rana, Escenario y Temporizador. Elementos principales:

Objetos: representan las instancias de las clases que participan en la comunicación. Se muestran como rectángulos con el nombre del objeto.
Mensajes: indican la comunicación entre los objetos. Se representan como ﬂechas que conectan los objetos y pueden incluir el nombre del mensaje y los parámetros.
Roles: deﬁnen el papel que juega un objeto en la interacción. Se pueden mostrar como etiquetas en los objetos.
Conectores: líneas que unen los objetos y representan la relación entre ellos.

Diagrama 6: Diagrama de secuencia del evento de colisión entre Rana y Auto

Jugador r1: Rana a: Auto [esCierto] notiﬁcarColisión() detectarColisión()

Notas: comentarios o aclaraciones que pueden añadirse al diagrama para proporcionar información adicional.
Numeración de mensajes: indica el orden de los mensajes enviados entre los objetos, generalmente numerados secuencialmente. 5.4. Diagrama de estados El diagrama de estados (o state machine diagram) representa el ciclo de vida de un objeto, mostrando los diferentes estados por los que pasa y los eventos o transiciones que provocan el cambio entre ellos. Es especialmente útil cuando una clase presenta comportamientos dependientes de su estado interno, como ocurre en videojuegos, sistemas bancarios o control de dispositivos. Elementos principales
Estado: situación en la que un objeto permanece durante un tiempo (rectángulo redondeado).
Transición: ﬂecha que indica el cambio de un estado a otro.
Evento o disparador: condición que provoca la transición. Partida + iniciar() Jugador Rana + mover() + veriﬁcarColisión() ControladorPartida + actualizar() + veriﬁcar() 2: mover() 2: iniciar() 2.1: veriﬁcarColisión() 2: mover() Diagrama 7. Diagrama de comunicación entre objetos principales de una partida Fuente: ChatGPT (2023)
Estado inicial y ﬁnal: representados con círculos sólido (inicio) y doble (ﬁnal).
Acciones: operaciones que ocurren al entrar, permanecer o salir de un estado. Ejemplo aplicado al caso Frogger Multiplayer En el objeto Rana, se pueden identiﬁcar los siguientes estados:
En espera: la partida aún no comienza.
Saltando: la rana se desplaza a una nueva posición.
Colisionada: ha chocado con un obstáculo.
En meta: ha alcanzado la meta ﬁnal.
Fuera del tablero: ha caído o perdido una vida. Cada evento (por ejemplo, detectarColisión() o alcanzarMeta()) provoca una transición de estado y puede ejecutar acciones asociadas, como restar vidas o aumentar el puntaje. Representación gráﬁca Diagrama 8. Diagrama de estados de la clase Rana en Frogger Multiplayer

Relación con los demás diagramas

El diagrama de estados complementa al diagrama de secuencia, ya que muestra la evolución del objeto a lo largo del tiempo.
Mientras el diagrama de secuencia enfatiza los mensajes intercambiados entre objetos, el de estados describe cómo un solo objeto cambia internamente en respuesta a esos mensajes.
En UML, ambos deben derivarse de los casos de uso para mantener la coherencia del modelo. Tipo de diagrama Propósito principal Enfoque Ejemplo en Frogger Multiplayer Representar ﬂujos de procesos o acciones. Actividades Flujo funcional. Secuencia de acciones de juego. Mostrar mensajes entre objetos ordenados en el tiempo. Secuencia Flujo temporal. Evento de colisión o movimiento. Visualizar la cooperación entre objetos. Comunicación Estructura de vínculos. Interacción Partida–Jugador –Escenario.

📐 Comparación entre diagramas de comportamiento UML

Tabla 1. Comparación entre diagramas de comportamiento UML Fuente: ChatGPT (2023)

Los diagramas UML de comportamiento complementan los diagramas estructurales al ofrecer una perspectiva dinámica del sistema. Permiten visualizar cómo las clases y objetos interactúan, se comunican y cambian de estado frente a eventos. El caso Frogger Multiplayer demuestra que el polimorﬁsmo, la colaboración entre objetos y la deﬁnición clara de contratos de clase son claves para lograr sistemas robustos, extensibles y fáciles de mantener. Entender y aplicar estos modelos prepara al estudiante para diseñar software profesional siguiendo buenas prácticas de ingeniería.

💡 Conclusión

🚀 Potencia tus proyectos tecnológicos con Proyecto Luna

En Proyecto Luna desarrollamos arquitectura de software de alto rendimiento, optimización de bases de datos críticas y soluciones aplicadas de inteligencia artificial y automatización para empresas y profesionales.

💼 Soluciones de ingeniería: Conoce nuestras capacidades y casos de estudio en proyectoluna.com/work/.
🛡️ Seguridad y auditoría: Orientación técnica y respuesta ante incidentes en ¿Te han hackeado?.
📩 Contacto directo: Escríbenos a través de nuestro formulario de contacto o a contacto@proyectoluna.com.

📚 Fuentes y lecturas recomendadas

● Booch, G., Rumbaugh, J. y Jacobson, I. (2006). El Lenguaje Uniﬁcado de Modelado: Guía del usuario (2ª ed.). Pearson/Addison Wesley. ● Jacobson, I., Booch, G. y Rumbaugh, J. (2000). El proceso uniﬁcado de desarrollo de software. Pearson Educación. ● Larman, C. (2005). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall. ● Meyer, B. (1988). Object-Oriented Software Construction. Prentice Hall. Pressman, R. S. (2020). Ingeniería del software: Un enfoque práctico (9ª ed.). McGraw-Hill. ● Sommerville, I. (2016). Ingeniería del software (10ª ed.). Pearson Educación.

Diagrama explicativo