Sistemas Reactivos: Diagramas de Estados y Actividades en UML

📌 En síntesis: Modelado del ciclo de vida de objetos y flujos de procesos: estados, transiciones, eventos de guarda, y diagramas de actividades con bifurcaciones.

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

📌

📌 Aprendizaje esperado

📌

Aplicar los conceptos de clase y objetos para diseñar con UML las clases que representan la estructura de un sistema a partir de los casos de uso. Aplicar los conceptos de clase y objetos para diseñar con UML las clases, y relaciones entre ellas, que representan la estructura de un sistema a partir de los casos de uso.

🚀 Introducción

El diseño orientado a objetos constituye uno de los pilares más sólidos en el desarrollo de software moderno. A través de los conceptos de clase, objeto, estado, atributos y relaciones, se logra representar sistemas complejos de una forma más cercana a la realidad, facilitando la comprensión y mantenimiento del software. En el marco del Lenguaje Uniﬁcado de Modelado (UML), los diagramas de estructura (especialmente el diagrama de clases y el diagrama de objetos) ofrecen herramientas visuales para sintetizar cómo se organiza un sistema y cómo se vinculan sus componentes internos. Estos diagramas son esenciales en la fase de diseño, pues permiten establecer la arquitectura lógica que dará soporte a las funcionalidades identiﬁcadas en los casos de uso. El presente documento aborda en profundidad los conceptos de objetos y clases, la función de los atributos y estados, el papel de los diagramas UML de estructura, y las relaciones entre clases y objetos. Asimismo, se ofrecen ejemplos prácticos contextualizados en sistemas conocidos (como el caso Frogger Mobile y un sistema de reservas de hotel), con el ﬁn de consolidar la aplicación de estos conceptos en situaciones reales.

1.1. Concepto de objetos y su estado Un objeto es una entidad concreta dentro de un sistema de software, que representa una instancia especíﬁca de una clase. Mientras que la clase deﬁne la plantilla abstracta con los atributos y comportamientos que caracterizan a un conjunto de entidades, el objeto constituye la materialización particular de esa plantilla en un contexto de ejecución. Dicho de otro modo, la clase es el molde y el objeto es el producto resultante de aplicarlo a una situación real. Cada objeto posee tres características esenciales que lo distinguen: El estado de un objeto es, por tanto, dinámico y depende tanto de los eventos externos (acciones de otros objetos o del usuario) como de las reglas internas deﬁnidas en la clase. Dicho estado se mantiene en memoria mientras el objeto existe, y en algunos casos puede persistir o ser almacenada en bases de datos para que su información se recupere posteriormente.

⚙️ Estructura de un sistema

Tabla 1. Características esenciales del objeto Fuente: ChatGPT (2023) Características Descripción Orientación al cliente Cada objeto se diferencia de los demás, incluso si sus atributos tienen los mismos valores. Por ejemplo, dos habitaciones de hotel con idéntico tipo y precio siguen siendo objetos distintos porque representan instancias diferentes en el sistema. Corresponde al conjunto de valores que adoptan los atributos de un objeto en un instante determinado. Este estado puede cambiar a lo largo del tiempo mediante la ejecución de métodos o la recepción de mensajes. Por ejemplo, en un videojuego como Frogger, el objeto Rana puede tener como estado inicial tres vidas, posición (0,0) y velocidad baja, pero al avanzar la partida estos valores cambian (dos vidas, posición (3,4), velocidad media). Se reﬁere a las operaciones o métodos que un objeto puede ejecutar y que, a menudo, modiﬁcan su estado o generan interacciones con otros objetos. Por ejemplo, la operación mover() en el objeto Vehículo cambia su posición en el escenario y puede afectar al estado de la Rana si ocurre una colisión. Evidencia para decisiones Estado

El análisis del estado de un objeto incluye:

Atributos esenciales: aquellos que describen la información mínima para diferenciar al objeto dentro del dominio del problema.
Restricciones e invariantes: condiciones que siempre deben cumplirse, como que la fecha de salida de una reserva sea posterior a la fecha de entrada.
Ciclo de vida: las fases por las que pasa un objeto, desde su creación hasta su destrucción, incluyendo cambios intermedios de estado. UML permite representarlo a través de diagramas de estados, útiles para modelar entidades con comportamientos dependientes de eventos, como el proceso de una Reserva (pendiente conﬁrmada cancelada ﬁnalizada). Ejemplo aplicado: En el sistema Frogger Mobile:
La clase Rana puede dar origen a múltiples objetos rana1, rana2, etc.
El estado de rana1 podría estar deﬁnido por atributos como posiciónX=5, posiciónY=3, vidas=2.
Su comportamiento incluye métodos como saltar(), moverIzquierda(), perderVida(). El estado de un objeto es dinámico y puede cambiar con el tiempo, dependiendo de las operaciones realizadas y las interacciones con otros objetos. 1.2. Concepto de clases y atributos Una clase es la deﬁnición abstracta que agrupa a objetos con características y comportamientos comunes. Las clases especiﬁcan los atributos (propiedades o datos) y los métodos (operaciones) que sus objetos tendrán.
Atributos: deﬁnen el estado del objeto. Incluyen nombre, tipo de dato y visibilidad.
Métodos: deﬁnen las acciones que el objeto puede realizar. En UML, las clases se representan como rectángulos divididos en tres compartimentos: 1. Nombre de la clase. 2. Lista de atributos. 3. Lista de métodos. Ejemplo aplicado: La clase Reserva en un sistema de hotel puede incluir:
Atributos: fechaEntrada: Date, fechaSalida: Date, estado: String.
Métodos: conﬁrmarReserva(), cancelarReserva(). De esta manera, la clase actúa como la plantilla conceptual a partir de la cual se generan objetos concretos. Los diagramas UML de estructura son una de las herramientas más importantes dentro del Lenguaje Uniﬁcado de Modelado (UML), ya que permiten representar la organización estática de un sistema de software. Mientras los diagramas de comportamiento muestran la dinámica de las interacciones y procesos, los diagramas de estructura se enfocan en capturar la arquitectura estable y permanente del sistema: las clases, objetos, componentes y sus relaciones. Su propósito es proporcionar una visión clara y organizada de los elementos que componen el sistema y de cómo se vinculan entre sí para sostener las funcionalidades identiﬁcadas en los casos de uso. En este sentido, actúan como un “mapa conceptual técnico” que guía tanto el diseño como la posterior implementación del software. Características principales de los diagramas de estructura

🌐 Principios de la Gestión de la Calidad

2.1. Diagrama de clases El diagrama de clases es la representación más utilizada en UML, ya que muestra:

Las clases del sistema.
Sus atributos y métodos.
Las relaciones entre ellas (asociación, herencia, agregación, composición). Se utiliza en la fase de diseño para establecer la estructura lógica y sirve como base para la implementación del sistema. Ejemplo general de diagrama de clases Tabla 2. Características diagramas de estructura Fuente: ChatGPT (2023)

Figura 1. Ejemplo general de diagrama de clases (Fuente: Wikimedia Commons (2007))

Características Descripción Enfoque estático Describen elementos del sistema que permanecen relativamente constantes en el tiempo, a diferencia de la lógica de ejecución. Pueden construirse desde niveles conceptuales (modelado de dominio) hasta niveles de diseño detallado (clases listas para codiﬁcarse). Lo que se modela en estos diagramas suele trasladarse a estructuras de código, repositorios de datos y relaciones en tiempo de ejecución. Base para la implementación Nivel de abstracción Sirven como medio de comunicación entre analistas, diseñadores, programadores y clientes, ya que visualizan la arquitectura sin necesidad de código. Lenguaje común

Diagrama de clases con relaciones entre ellas Simbología de relaciones (UML)

Figura 2. Diagrama de clases con relaciones entre ellas (Fuente: ChatGPT (2023))

Tabla 3. Simbología de relaciones (UML) Fuente: ChatGPT (2023) Relación Notación/Trazo ¿Cuándo usarla? Pista visual Asociación Línea sólida; puede tener roles, navegabilidad (ﬂecha abierta) y multiplicidad Dos clases colaboran o intercambian información Línea simple; añade nombre de rol y multiplicidad en cada extremo Dependencia Línea discontinua con ﬂecha abierta Un elemento usa a otro de forma no estructural Flecha discontinua Realización Línea discontinua con triángulo blanco Clase concreta implementa una interfaz Flecha discontinua con triángulo hueco Generalización (Herencia) Flecha con triángulo blanco hacia la superclase Especialización/ jerarquía de tipos Triángulo hueco apuntando a la superclase Composición Asociación con rombo negro en el “todo” Relación todo–parte fuerte (la parte no existe sin el todo) Rombo negro en el lado “todo” Asociación con rombo blanco en el “todo” Relación todo–parte débil (la parte puede existir sin el todo) Rombo blanco en el lado “todo” Agregación

Ejemplo: Bicicleta: asociación vs. agregación vs. Composición En este ejemplo:

La Bicicleta(Bicycle) se asocia a un Propietario
La Bicicleta(Bicycle) se compone de elementos o partes
La Bicilceta(Bicycle) debe tener RuedasA veces, se desea modelar una relación “todo/parte”, en la cual una clase representa una cosa grande (el “todo”), qué consta de elementos más pequeños (las “partes”). Este tipo de relación se denomina agregación, la cual representa una relación del tipo “tiene-un”, o sea, un objeto del todo tiene objetos de la parte. En realidad, la agregación es sólo un tipo especial de asociación y se especiﬁca añadiendo a una asociación normal un rombo vacío en la parte del todo.

Figura 3. Ejemplo asociación vs. agregación vs. Composición (Fuente: Wikimedia Commons (2007))

Figura 4. Ejemplo de Asociación/Agregación (Fuente: ChatGPT (2023))

2.2. Multiplicidad entre clases (≈ “cardinalidad” en modelos de datos) La multiplicidad anota cuántas instancias de una clase pueden estar vinculadas a otra a través de una asociación. Se escribe junto a cada extremo de la relación. Elementos y símbolos en los diagramas de clases UML

Figura 5. Elementos y símbolos en los diagramas de clases UML (Fuente: Wikimedia Commons (2007))

Tabla 4. Multiplicidad Fuente: ChatGPT (2023) Buenas prácticas: especiﬁca la multiplicidad en ambos extremos, nombra los roles (por ejemplo, juego/obstaculos) y deﬁne la navegabilidad si procede. Esto evita ambigüedades al pasar del modelo al código o a la base de datos Exactamente unación 0..1 Opcional (cero o una) * o 0..* Muchos (cero o más) 1..* Uno o más m..n Entre m y n

Ejemplos aplicados (Frogger Mobile):

Juego 1 1 Rana: un juego controla exactamente una rana.
Juego 1 0..* Obstaculo: un juego administra cero o muchos obstáculos.
Obstaculo 1 1..* Posicion: cada obstáculo ocupa una o más celdas (si modelas segmentos de tronco/vehículo).
Rana 1 0..1 Tronco: la rana puede estar en cero o un tronco en un instante. Agregación vs. Composición (cuándo usar cada una):
Agregación ( ): usa cuando la parte puede existir fuera del todo. Ej.: Juego Obstaculo si un obstáculo se reutiliza en un editor de niveles.
Composición ( ): usa cuando la parte depende del todo para existir. Ej.: Vehiculo Rueda (si eliminas el vehículo, desaparecen sus ruedas). 2.3. Diagrama de objetos El diagrama de objetos es un elemento gráﬁco de instancia del diagrama de clases, en el cual se representan objetos concretos y sus valores actuales.
Se enfoca en el estado en un momento especíﬁco del sistema.
Sirve para validar los modelos de clases, ya que permite comprobar cómo se materializan las relaciones y estados. Ejemplo aplicado:
Objeto rana1: Rana con vidas=3, posiciónX=5, posiciónY=7.
Objeto vehiculo1: Vehiculo con tipo=Camión, velocidad=2.
Objeto tronco1: Tronco con longitud=4, dirección=izquierda. Este diagrama resulta útil para simular escenarios de uso y veriﬁcar si las relaciones deﬁnidas en el diagrama de clases son consistentes. Las relaciones entre objetos son los vínculos dinámicos que se generan entre instancias concretas de clases durante la ejecución de un sistema. Mientras que las clases deﬁnen las posibilidades estructurales de asociación (lo que podría pasar), las relaciones entre objetos representan lo que realmente ocurre en un momento dado del programa, reﬂejando cómo los objetos colaboran para cumplir los escenarios descritos en los casos de uso. En otras palabras:
Una asociación entre clases describe una relación potencial (“un cliente puede realizar una reserva”).
Una relación entre objetos muestra una relación efectiva en tiempo de ejecución (“el cliente Juan Pérez realizó la reserva #1234 para la habitación 202”).

Figura 6. Ejemplo Diagrama de objetos (Fuente: ChatGPT (2023))

🧩 Relaciones entre objetos

Características principales de las relaciones entre objetos 3.1. Enlaces Un enlace es la conexión entre dos objetos en un momento dado, como una instancia de una asociación deﬁnida a nivel de clases. Ejemplo aplicado:

Objeto reserva1: Reserva está enlazado con el objeto cliente1: Cliente.
En Frogger Mobile, el objeto rana1: Rana puede estar enlazado al objeto juego1: Juego, durante una partida activa. 3.2 Agregación entre objetos La agregación a nivel de objetos indica una relación de “todo-parte” en la cual las partes pueden existir independientemente del todo. Ejemplo aplicado:
En un sistema de hotel, el objeto hotel1: Hotel agrega múltiples objetos habitacion101: Habitacion, habitacion102: Habitacion.
En Frogger Mobile, el objeto nivel1: Nivel agrega los objetos tronco1: Tronco y vehiculo1: Vehiculo. Tabla 5. Características principales de las relaciones entre objetos Fuente: ChatGPT (2023 Características Descripción Carácter dinámico Aparecen, cambian o desaparecen durante la vida del sistema, dependiendo de la interacción de los usuarios y de los procesos internos. Concreción Se establecen entre instancias reales, no entre deﬁniciones abstractas. Multiplicidad real Aunque una clase pueda estar asociada a “muchas” otras, en un momento concreto puede estar relacionada con pocas o ninguna. Contextualidad Un mismo objeto puede estar relacionado con distintos objetos en diferentes contextos

🧩 Relaciones entre clases

Mientras que las clases deﬁnen atributos y comportamientos individuales, las relaciones establecen cómo estas clases interactúan, dependen y se organizan entre sí, formando una arquitectura coherente. En otras palabras, una clase por sí sola representa solo una pieza aislada del sistema. Lo que realmente permite construir soluciones completas es el tejido de relaciones entre múltiples clases, donde cada una asume un rol particular dentro de un todo mayor. Características principales relación de clases 4.1. Asociación La asociación representa una relación estructural entre dos clases que pueden interactuar. Ejemplo aplicado:

Clase Cliente asociada con Reserva.
En Frogger Mobile, clase Juego asociada con clase Puntaje. Tabla 6. Características principales de las relaciones de clases Fuente: ChatGPT (2023) Características Descripción Carácter estructural Las relaciones son estáticas y se mantienen a lo largo del diseño, independientemente de la ejecución concreta del sistema. Reﬂejan vínculos del mundo real, como propiedad, dependencia, especialización o colaboración entre entidades. Una relación bien deﬁnida reduce duplicación, clariﬁca responsabilidades y facilita la evolución del sistema. Soporte para reutilización y mantenibilidad Semántica de dominio UML contempla diversos tipos de relaciones (asociación, dependencia, agregación, composición, herencia), cada una con un signiﬁcado especíﬁco. Tipología variada

4.2. Agregación La agregación indica una relación “todo-parte” donde el ciclo de vida de las partes es independiente del todo. Ejemplo aplicado:

Clase Nivel agrega múltiples Obstáculo.
Clase Hotel agrega múltiples Habitación. 4.3. Herencia (Generalización) La herencia establece una relación jerárquica entre una clase general y sus especializaciones. Ejemplo aplicado:
Clase Persona es generalización de Cliente y Recepcionista, es decir un Cliente es una Persona, pero que, además, posee ciertas características especíﬁcas
En Frogger Mobile, clase Obstáculo es generalización de Vehículo y Tronco. Comprender con claridad los conceptos de clases, objetos, atributos y métodos, así como sus estados y relaciones, es lo que permite transformar los requerimientos de negocio en modelos de software coherentes, mantenibles y escalables. Sin esta comprensión, el diseño corre el riesgo de convertirse en un conjunto desordenado de piezas inconexas, difíciles de implementar y aún más complicadas de evolucionar en el tiempo. El Lenguaje Uniﬁcado de Modelado (UML) ofrece un estándar visual y conceptual que facilita la representación de esta estructura. Los diagramas de clases permiten establecer la visión global del sistema, identiﬁcando los elementos esenciales y las relaciones estáticas que los vinculan. Los diagramas de objetos, por su parte, muestran cómo esas estructuras se materializan en instancias concretas durante la ejecución, lo que ayuda a validar el modelo y comprobar que responde de manera efectiva a los casos de uso planteados. Dominar estos diagramas y las distintas formas de relación —asociación, agregación, herencia, composición, enlaces entre objetos— implica no solo aprender una notación, sino también interiorizar la lógica de diseño orientado a objetos: cómo distribuir responsabilidades, cómo evitar dependencias innecesarias, cómo garantizar la cohesión interna de las clases y cómo mantener bajo acoplamiento entre módulos. En la práctica, esta capacidad es decisiva. En un proyecto como Frogger Mobile, identiﬁcar correctamente clases como Rana, Juego u Obstáculo y establecer sus relaciones asegura que el sistema pueda ampliarse con nuevos niveles, modos de juego o funcionalidades sin necesidad de reescribirlo desde cero. De la misma manera, en un sistema de gestión empresarial, un modelo bien estructurado de clases y objetos permite incorporar nuevos procesos de negocio con menor esfuerzo y riesgo. En deﬁnitiva, la estructuración clara y rigurosa de un sistema mediante UML no solo impacta en la fase de diseño, sino en todo el ciclo de vida del software. Aporta un lenguaje común entre todos los involucrados (analistas, diseñadores, programadores, testers y clientes), fomenta la documentación de calidad, y sienta las bases para

💡 Conclusión

sistemas que puedan crecer, adaptarse y mantenerse en entornos cambiantes. Un buen diseño estructural es, por tanto, la diferencia entre un proyecto que evoluciona de manera sostenible y otro que se ve atrapado por su propia complejidad.

Booch, G., Rumbaugh, J. y Jacobson, I. (2006). El lenguaje uniﬁcado de modelado: guía del usuario. Pearson.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000). El proceso uniﬁcado de desarrollo de software. Addison-Wesley.
Open AI. (2023). Chat GPT [Modelo de lenguaje modelado].
Pressman, R. (2010). Ingeniería de software: un enfoque práctico. McGraw-Hill.
Sommerville, I. (2011). Ingeniería del software (9.ª ed.). Pearson. Wikimedia Foundation. (s. f.). Wikimedia Commons.

🚀 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.