📌 En síntesis: Representación temporal del flujo de mensajes: líneas de vida, mensajes síncronos/asíncronos, retornos y fragmentos combinados (alt, opt, loop).

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

---

📌 Aprendizaje esperado

---

📌

Calcular voltajes y corrientes de mallas y nodos de acuerdo con especificaciones dadas.

---

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

El desarrollo de software orientado a objetos ha marcado un hito en la evolución de la ingeniería de software, consolidándose como un enfoque esencial para el diseño y construcción de sistemas complejos, flexibles y mantenibles. Este paradigma, basado en la noción de representar el mundo real mediante clases y objetos, permite abordar los problemas de diseño desde una perspectiva cercana a la manera en que las personas entienden y organizan la realidad: a través de entidades que poseen atributos y comportamientos. En el marco del , la correcta aplicación de los principios del modelo de objetos es decisiva para lograr arquitecturas que no solo funcionen, sino que también puedan evolucionar con el tiempo. Estos principios constituyen la base conceptual que orienta las decisiones técnicas y organizativas, y encuentran su representación práctica en los diagramas UML, especialmente en el diagrama de clases, que actúa como una síntesis estructural del sistema. Este documento aborda los elementos fundamentales del modelo de objetos —abstracción, encapsulamiento, modularidad y jerarquía—, que proporcionan las bases para la organización y estructuración de cualquier sistema. Asimismo, se examinan los elementos secundarios —concurrencia y persistencia—, que, aunque no siempre presentes en todos los proyectos, resultan esenciales en sistemas que requieren atención simultánea de múltiples usuarios, procesamiento paralelo de tareas o almacenamiento de datos de manera estable y duradera. A su vez, descubrirás cómo se crean clases, con sus elementos y de qué modo se establecen sus relaciones dependiendo del contexto.

---

🚀 Introducción

---

🧩 Elementos fundamentales en el modelo de objetos

1.1. Abstracción La abstracción es el proceso de enfocarse en las características esenciales de un objeto, ignorando los detalles irrelevantes. En programación orientada a objetos (POO), abstraer significa definir qué atributos y métodos son necesarios para representar una entidad dentro del sistema. Por ejemplo, durante semana anterior, pudiste ver un caso de reservas de hotel. Por ejemplo, en tal contexto, si se define la clase [Habitación], lo relevante podría ser: número, tipo, estado (disponible/ocupada), y precio. No tendría sentido incluir en la clase, detalles como el color de las cortinas o el material del piso, salvo que sean necesarios para la lógica del negocio. La abstracción facilita la gestión de la complejidad, ya que permite trabajar con representaciones manejables y centrarse en lo esencial. En UML, la abstracción se refleja en la identificación de clases y atributos que responden a los requisitos planteados en los casos de uso. 1.2. Encapsulamiento El encapsulamiento es el principio según el cual los datos de un objeto están protegidos y solo pueden ser accedidos o modificados a través de operaciones definidas. Esto se traduce en el uso de visibilidad de atributos y métodos (públicos, privados o protegidos). En el mismo sistema de reservas, la clase [Reserva] podría tener el atributo [estadoReserva]. Este no debería modificarse directamente desde fuera de la clase (ejemplo: [reserva.estadoReserva = “cancelada”]), sino mediante un método controlado ([cancelarReserva()]). Esto garantiza consistencia y evita que un usuario externo altere arbitrariamente la información.

En UML, el encapsulamiento se representa con símbolos de visibilidad:

• [+] Público.
• [-] Privado.
• [#] Protegido. Este principio asegura la integridad del sistema, previniendo inconsistencias y errores comunes en el manejo de datos. 1.3. Modularidad La modularidad consiste en dividir un sistema en componentes o módulos independientes que interactúan entre sí de manera controlada. Cada clase representa un módulo dentro del modelo de objetos. La ventaja de la modularidad es doble: 1. Mantenibilidad: los cambios en un módulo no afectan directamente a otros, siempre que se respeten las interfaces. 2. Reutilización: un módulo bien definido puede usarse en otros proyectos o contextos. En UML, la modularidad se refleja no solo en el diagrama de clases, sino también en los paquetes, que agrupan clases relacionadas. Por ejemplo, el sistema del Hotel Paraíso podría dividirse en los paquetes [GestiónReservas], [GestiónClientes] y [GestiónPagos]. 1.4. Jerarquía La jerarquía se refiere a las relaciones de generalización/especialización entre clases. Es el fundamento de la herencia en POO. Por ejemplo, en el sistema del hotel, podríamos definir una clase general [Persona] con atributos comunes como [nombre], [correo] y [teléfono], y a partir de ella especializar [Cliente], [Recepcionista] y [Administrador].

La jerarquía permite reutilizar atributos y métodos, evitando duplicación de código y facilitando la organización del modelo. En UML, se representa con la flecha de generalización ( ). 1.5. Concepto y definición de Clase En el Paradigma Orientado a Objetos, el elemento fundamental y punto de partida es la Clase. Para ello, cada clase debe:

• Tener un nombre que la distinga de otras “Clase”.

• Un atributo es una propiedad de una clase identificada con un nombre. Una clase puede tener cualquier número de atributos o no tener ninguno. Un atributo representa alguna propiedad del elemento que se está modelando, que es compartido por todos los objetos de esa clase. Por ejemplo, toda pared tiene una altura, una anchura y un grosor. Un atributo es, por tanto, una abstracción de un tipo de dato o estado que puede incluir un objeto de la clase.

• En un momento dado un objeto de una clase tendrá valores específicos para cada uno de los atributos de su clase.

• Una operación (de una clase) que es la implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento. En otras palabras, una operación es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase.

• A menudo (pero no siempre) la invocación de una operación sobre un objeto cambia los datos o el estado del objeto.

• Una responsabilidad (de una clase) es un contrato o una obligación de una clase. Al crear una clase, se está expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento. 1.6. Simbología del diagrama de clases UML En UML, los diagramas de clases utilizan una simbología estandarizada que permite representar de manera clara los distintos elementos:

Asociación: línea simple entre clases. Agregación: línea con rombo blanco en el extremo del todo. Composición: línea con rombo negro, indicando dependencia total de las partes con respecto al todo. Herencia (generalización): flecha con triángulo vacío hacia la superclase. Dependencia: línea discontinua con flecha, muestra un uso temporal de una clase por otra. Clases Nombre de clase Lista de atributos Lista de métodos Visibilidad de atributos y métodos Público: accesible desde cualquier otra clase Privado: accesible solo dentro de la propia clase Protegido: accesible desde la lase y sus subclases + - # Relaciones

Figura 1. Ejemplo sistema de reservas de hotel (Fuente: ChatGPT (2023))

Clases: rectángulo dividido en tres compartimentos: 1. Nombre de la clase. 2. Lista de atributos. 3. Lista de métodos. Visibilidad de atributos y métodos:

• • Público: accesible desde cualquier otra clase.
• • Privado: accesible solo dentro de la propia clase.

• Protegido: accesible desde la clase y sus subclases.

Relaciones:

• Asociación: línea simple entre clases.

• Agregación: línea con rombo blanco en el extremo del todo.

• Composición: línea con rombo negro, indicando dependencia total de las partes con respecto al todo.

• Herencia (generalización): flecha con triángulo vacío hacia la superclase.

• Dependencia: línea discontinua con flecha, muestra un uso temporal de una clase por otra.

Figura 2: Clases del sistema de reservas de hotel (ejemplo)

🔹 Ejemplo de diagrama de clases UML

Para comprender cómo los elementos fundamentales del modelo de objetos (abstracción, encapsulamiento, modularidad y jerarquía) se representan en la práctica, resulta útil observar un diagrama de clases UML aplicado a un caso real. Ejemplo aplicado: sistema de reservas de hotel En este sistema, podemos identificar las siguientes clases: Las relaciones entre estas clases se reflejan de la siguiente manera:

• Un Cliente puede realizar múltiples Reservas (asociación con multiplicidad 1..*).

• Una Reserva se vincula a una única Habitación (asociación 1 a 1).

• La clase Persona se generaliza en Cliente y Recepcionista (herencia). Con atributos como: nombre , correo , teléfono. Cliente Con atributos como: fechaEntrada , fechaSalida , estado. Reserva Con atributos como: número , tipo , precio. Habitación Con atributos como: idEmpleado y turno. Recepcionista

Figura 3: Ejemplo sistema de reservas de hotel

Cliente + nombre: String + correo: String + teléfono: String Persona Recepcionista + idEmpleado: int + turno: String Reserva + fechaEntrada Date + correo: String + teléfono: String Habitación + número int + tipo: String 1..* Para más ejemplos de Diagrama de Clases, consulta el siguiente enlace: Ejemplo de Modelo de clases.

Además de los principios fundamentales de la orientación a objetos, existen elementos considerados secundarios porque no están presentes en todos los sistemas, pero resultan esenciales en entornos reales donde los sistemas deben atender múltiples usuarios, procesar grandes volúmenes de información o mantener estados de manera confiable a lo largo del tiempo. Los dos elementos secundarios más relevantes en el modelo de objetos son la concurrencia y la persistencia. 2.1. Concurrencia La concurrencia se refiere a la capacidad de un sistema para manejar múltiples tareas o procesos de forma simultánea o solapada, de manera que varios objetos puedan estar activos e interactuando al mismo tiempo. En términos prácticos, esto significa que el sistema debe estar preparado para responder a varios usuarios o procesos de negocio de manera coordinada, sin perder consistencia ni generar bloqueos. a) Importancia de la concurrencia Tabla 1. Importancia de la concurrencia Fuente: ChatGPT (2023)

---

🧩 Elementos secundarios en el modelo de objetos

Criterio Descripción Eficiencia Un sistema concurrente aprovecha mejor los recursos del hardware, como procesadores multinúcleo. Escalabilidad Permite que el sistema pueda atender a cientos o miles de usuarios al mismo tiempo, algo esencial en aplicaciones web, bancarias o de telecomunicaciones. Experiencia de usuario La concurrencia evita bloqueos, lo que da la sensación de fluidez en aplicaciones críticas.

b) Ejemplo aplicado al sistema del Hotel Paraíso En el sistema de reservas, la concurrencia es fundamental porque:

• Varios clientes pueden intentar reservar habitaciones al mismo tiempo desde la web.

• Un recepcionista podría estar confirmando una reserva mientras otro está modificando una ya existente.

• Un administrador puede estar generando reportes en paralelo al resto de operaciones. Si no existiera un manejo adecuado de la concurrencia, podrían generarse errores como:

• Sobreventa de habitaciones (dos clientes reservan la misma habitación al mismo tiempo).

• Datos inconsistentes en el historial de reservas.

• Bloqueos en la aplicación cuando dos usuarios compiten por el mismo recurso. c) Concurrencia en UML En UML, la concurrencia puede representarse mediante:

• Diagramas de actividades, con ramas paralelas (barras de bifurcación y sincronización).

• Diagramas de estados, que muestran objetos con múltiples hilos de ejecución activos.

• Clases activas, que indican objetos con su propio hilo de control, representadas en UML con bordes más gruesos.

En conclusión, la concurrencia es lo que permite que un sistema orientado a objetos pase de ser un diseño teórico a una aplicación práctica capaz de responder a escenarios reales de uso simultáneo. 2.2. Persistencia La persistencia es la capacidad de los objetos para mantener su estado de manera duradera, más allá de la ejecución del programa. Esto implica que los datos no se pierden cuando la aplicación finaliza, sino que se almacenan y pueden recuperarse en futuras ejecuciones. a) Importancia de la persistencia

• Confiabilidad: garantiza que la información relevante se conserve a largo plazo.

• Historial de datos: permite registrar acciones pasadas, algo fundamental para auditorías y trazabilidad.

• Interoperabilidad: posibilita que los sistemas compartan información entre sesiones y usuarios. Tabla 2. Estrategias de diseño para manejar concurrencia Fuente: ChatGPT (2023) Estrategias de diseño Descripción Bloqueo y sincronización Asegurar que solo un proceso pueda modificar un objeto crítico a la vez. Transacciones Garantizar que una operación completa se ejecute de manera atómica. Colas y gestores de procesos Organizar solicitudes concurrentes para evitar conflictos. Diseño orientado a eventos Desacoplar procesos para que se gestionen en paralelo sin interferencias. d) Estrategias de diseño para manejar concurrencia

b) Ejemplo aplicado al sistema del Hotel Paraíso La persistencia es crítica porque:

• Una reserva debe mantenerse incluso si el sistema se reinicia, para que el cliente no pierda su confirmación.

• Los datos de los clientes deben estar disponibles en futuras reservas.

• Los reportes de ocupación necesitan consultar información histórica para detectar patrones de temporada. Sin persistencia, cada vez que se reiniciara el sistema, toda la información desaparecería, lo que haría inviable su uso en un hotel real. c) Persistencia en UML En UML, la persistencia puede reflejarse en diagramas de clases a través de:

• Estereotipos como <> en las clases que representan datos permanentes.

• Asociaciones con entidades de almacenamiento, como bases de datos o sistemas de archivos. Modelos conceptuales donde se vinculan las clases del sistema con tablas relacionales (en un modelo entidad-relación). d) Estrategias de diseño para la persistencia Estrategias de diseño Descripción Archivos planos Opción básica para guardar datos, poco usada en sistemas grandes. Bases de datos relacionales Con SQL para gestionar grandes volúmenes de datos estructurados. Bases de datos orientadas a objetos Que permiten almacenar directamente instancias de clases. ORM (Object-Relational Mapping) Herramientas como Hibernate o Entity Framework que simplifican la integración entre objetos y bases de datos relacionales. Tabla 3. Estrategias de diseño para la persistencia Fuente: ChatGPT (2023)

3.1. Simbología UML para asociaciones en diagramas de clases En los diagramas de clases, las asociaciones representan relaciones estructurales entre clases. Su notación incluye:

• Una línea simple que conecta las dos clases.

• Multiplicidad, que indica cuántas instancias de una clase pueden relacionarse con instancias de la otra. Ejemplos: o 1 significa una sola instancia. o 0..* significa cero a muchas. o 1..* significa al menos una.

• Rol de la relación, que especifica la función que cumple cada clase en la relación. Ejemplo aplicado:

• En el sistema de hotel, un Cliente puede tener 0..* Reservas, pero cada Reserva está asociada exactamente a 1 Cliente.

---

🧩 Ejemplos aplicados al diseño UML de clases a

---

🛠️ partir de casos de uso

ClaseA ClaseB ClaseA ClaseB 0..* 0..* rolDeLaRelación

Figura 4: Asociaciones y multiplicidades

Supongamos el caso de uso: “Registrar reserva”.

• Se identifican los actores: [Cliente] y [Recepcionista].

• Se definen las clases principales: [Reserva], [Habitación], [Cliente].

• Se aplican los principios: o Abstracción: definir solo atributos relevantes (fecha de entrada, fecha de salida, estado). o Encapsulamiento: usar métodos para modificar estados ([confirmarReserva()], [cancelarReserva()]). o Modularidad: organizar las clases en un paquete [GestiónReservas]. o Jerarquía: especializar [Persona] en [Cliente] y [Recepcionista]. o Concurrencia: múltiples clientes pueden reservar al mismo tiempo. o Persistencia: los objetos [Reserva] y [Cliente] se almacenan en la base de datos. Esto demuestra cómo los casos de uso se transforman en un modelo de clases UML que aplica los principios del modelo de objetos. 3.2. Asociaciones en UML Las asociaciones entre clases en UML son fundamentales para mostrar cómo las entidades del sistema colaboran entre sí. Ejemplo 1 – Sistema de reservas de hotel

• La clase Cliente se asocia con la clase Reserva mediante una relación de multiplicidad 1..*.

• La clase Recepcionista también se asocia con Reserva, indicando que un recepcionista puede gestionar varias reservas.

• La clase Habitación se asocia con Reserva en una relación 1 a 1, ya que cada reserva corresponde a una habitación específica.

Ejemplo 2 – Frogger Mobile

• La clase Juego se asocia con la clase Rana, indicando que cada partida de juego administra a una instancia de rana.

• El Juego también se asocia con la clase Obstáculo, que a su vez se generaliza en Vehículo y Tronco.

• Cada Obstáculo se asocia con un Nivel, que agrega todos los elementos presentes en la partida. Cliente + nombre Reserva +fechaEntrada +fechaSalida Recepcionista +idEmpleado Habitación +número La clase [Cliente] se asocia con la clase [Reserva] mediante una relación de 1…* La clase [Cliente] se asocia con la clase [Reserva] mediante una relación de multiplicidad 1…* La clase [Recepcionista] se asocia con [Reserva] en una relación 1 a , ya que cada reserva corresponde a una habitación específica. La clase [Habitación] se asocia con la clase [Reserva] en una relación de 1 a 1.

Figura 5: Asociaciones en UML - Frogger

Figura 5: Asociaciones en UML - Frogger (Fuente: ChatGPT (2023))

Juego iniciar() terminar() Rana vidas: int posición:Punto Rana vidas: int posición:Punto Nivel Agrega todos los elementos presentes en la partida Vehículo Velocidad: int Tronco Longitud: int Vehículo Mover() Cada partida de juego administra 1..*

El modelo de objetos constituye la base conceptual y práctica de la programación orientada a objetos y del moderno. No se trata únicamente de un conjunto de principios abstractos, sino de pautas de diseño y construcción que permiten transformar los requerimientos expresados en casos de uso en una arquitectura de clases clara, estructurada y sostenible. Cada Clase, a su vez, contiene atributos y comportamientos que reflejan su responsabilidad dentro del modelado del sistema. Los elementos fundamentales —abstracción, encapsulamiento, modularidad y jerarquía— ofrecen un marco sólido para organizar el pensamiento y las decisiones de diseño:

• La abstracción ayuda a centrarse en lo esencial de un sistema, evitando sobrecargar los modelos con detalles innecesarios.

• El encapsulamiento protege la integridad de los datos y asegura que los objetos interactúen de manera controlada, evitando inconsistencias.

• La modularidad permite dividir el sistema en componentes independientes, lo que facilita la mantenibilidad y la reutilización de código.

• La jerarquía, a través de la herencia y la especialización, favorece la organización lógica del modelo y potencia la reutilización. Por otro lado, los elementos secundarios —concurrencia y persistencia— son los que diferencian un sistema meramente conceptual de un sistema verdaderamente funcional en la práctica. La concurrencia asegura que múltiples usuarios o procesos puedan interactuar con el sistema de manera simultánea sin generar errores ni bloqueos, mientras que la persistencia garantiza que los datos sobrevivan más allá de la ejecución del programa, asegurando continuidad y trazabilidad. El lenguaje unificado de modelado (UML) es el puente entre la teoría y la práctica. Al usar diagramas de clases para representar abstracción, encapsulamiento, modularidad

---

💡 Conclusión

y jerarquía, y al considerar concurrencia y persistencia en diagramas de estados, actividades y clases persistentes, se logra una representación gráfica del sistema que conecta directamente con la implementación en código. Aplicar estos principios en el caso de estudio del Hotel Paraíso muestra que los conceptos no son solo ideas teóricas: son guías prácticas para diseñar sistemas reales. Por ejemplo, la abstracción permite definir clases relevantes como Cliente y Reserva; el encapsulamiento garantiza que el estado de una reserva solo pueda modificarse mediante operaciones específicas; la modularidad organiza el sistema en paquetes como GestiónReservas y GestiónPagos; la jerarquía unifica entidades en clases más generales como Persona; la concurrencia asegura que varios clientes puedan reservar habitaciones al mismo tiempo sin inconsistencias; y la persistencia garantiza que las reservas se almacenen de forma duradera en la base de datos. En síntesis, comprender y aplicar estos principios permite a las y los futuros profesionales de la informática convertir casos de uso en modelos de clases robustos y eficientes, capaces de evolucionar y adaptarse a cambios sin perder calidad ni estabilidad. Esto se traduce en proyectos más confiables, escalables y alineados con las demandas reales de la industria del software.

---

---

🚀 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 unificado de modelado: guía del usuario. Pearson. ● Jacobson, I., Booch, G. y Rumbaugh, J. (2000). El proceso unificado 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. ● Schmuller, J. (2004). Aprenda UML en 24 horas. Pearson Educación. Sommerville, I. (2011). Ingeniería del software (9.ª ed.). Pearson.