El modelado orientado a objetos es una etapa clave en el diseño de software, ya que permite transformar el análisis del problema en una estructura técnica compuesta por clases, objetos, atributos, métodos y relaciones, facilitando la representación organizada de las entidades del sistema mediante abstracciones que ayudan a manejar su complejidad .

Desde la perspectiva de la ingeniería de software, este modelado define la forma en que interactúan los componentes del sistema, sus responsabilidades y los mecanismos de comunicación entre ellos, lo que contribuye a mejorar la reutilización del código, la mantenibilidad y la extensibilidad del sistema .

En el ámbito de la ciberseguridad, el modelado orientado a objetos también permite incorporar principios de seguridad desde el diseño, como el control de acceso, el principio de privilegio mínimo, la encapsulación de información sensible y la separación de responsabilidades, garantizando que cada objeto solo pueda ejecutar las operaciones que le corresponden .

Un ejemplo de aplicación es el diseño de un sistema de acceso seguro mediante clases como Usuario, Rol, Permiso y Recurso, donde el acceso a los recursos se gestiona a través de roles y permisos asociados. Este enfoque corresponde al modelo RBAC (Role-Based Access Control), que permite una administración más flexible de los accesos al asignar permisos a roles en lugar de hacerlo directamente a los usuarios .

7.1 IDENTIFICACIÓN DE ELEMENTOS DEL MODELO

La identificación de elementos del modelo consiste en determinar qué entidades del dominio deben representarse como clases dentro del sistema, así como sus atributos, responsabilidades y relaciones.

La tabla 1 presenta la información organizada de los elementos de un sistema de control de acceso basado en roles, conocido como RBAC (Role-Based Access Control).

Para reforzar el conocimiento adquirido, invito a revisar el contenido del siguiente video, donde a más de se muestra la forma de identificar los elementos de un modelo orientado a objetos.

7.2 Encapsulamiento y visibilidad

Encapsulamiento: En la programación orientada a objetos, el encapsulamiento es el principio que consiste en agrupar datos (atributos) y comportamientos (métodos) dentro de una clase, restringiendo el acceso directo a sus componentes internos. Su objetivo es proteger la integridad de los datos y controlar cómo se modifican o consultan.

Visibilidad: La visibilidad, define los niveles de acceso a esos atributos y métodos mediante modificadores como private, protected y public .

Por ejemplo, en una clase Usuario, la contraseña no debe ser accesible directamente. En su lugar, se implementan métodos que controlan su uso, como la verificación:

public class Usuario {

//aquí otros atributos de la clase

private String passwordHash;

public boolean verificarPassword(String input) {

return passwordHash.equals(hash(input));

}

private String hash(String input) {

// lógica de cifrado

return input;

}

}

Aquí, el atributo passwordHash está encapsulado como privado, evitando que otras clases accedan directamente a él, esta es una práctica recomendada para proteger datos sensibles .

Los modificadores de visibilidad permiten implementar distintos niveles de acceso dentro del sistema:

• Privado (private): restringe el acceso únicamente a la propia clase. Es el nivel más seguro y debe utilizarse para proteger información crítica como contraseñas, tokens o claves. Este enfoque sigue el principio de ocultamiento de información, esencial en el diseño seguro .
• Protegido (protected): permite el acceso dentro de la clase y sus subclases. Es útil cuando se requiere reutilizar lógica en estructuras de herencia, por ejemplo, métodos de validación que serán extendidos por diferentes tipos de autenticación:

protected boolean validarCredenciales(String usuario, String password) {

// lógica común de validación

return true;

}

Sin embargo, su uso debe ser controlado, ya que amplía el alcance del acceso .

• Público (public): permite el acceso desde cualquier parte del sistema. Representa la interfaz visible, por lo que debe limitarse a los métodos estrictamente necesarios y siempre incluir validaciones. En un sistema de acceso seguro, estos métodos son el punto de entrada:

public boolean login(String usuario, String password) {

return verificarPassword(password);

}

Este diseño asegura que todas las operaciones pasen por controles definidos, lo cual es una práctica clave para construir sistemas robustos y mantenibles .

En una implementación, una clase como SistemaAutenticacion mantendría sus datos sensibles como privados, expondría únicamente métodos públicos para operaciones como autenticación, y utilizaría elementos protegidos solo cuando sea necesario compartir lógica entre clases relacionadas. Esto permite centralizar el control y reducir riesgos de seguridad.

En concreto, aplicar encapsulamiento correctamente implica seguir reglas claras, no exponer datos sensibles, validar siempre en los métodos públicos y aplicar el principio de mínimo privilegio. Un mal uso de la visibilidad puede comprometer el sistema completo, incluso si la lógica es correcta.

En el diseño de modelado orientado a objetos, uno de los aspectos más importantes es definir correctamente las relaciones entre las clases. Estas relaciones permiten representar cómo interactúan los objetos dentro del sistema y cómo se organiza la estructura lógica del software. En el contexto de ciberseguridad y control de acceso a sistemas, comprender estas relaciones es fundamental para diseñar arquitecturas seguras, mantenibles y desacopladas.

El modelado orientado a objetos no se limita a identificar clases, sino que incluye definir sus relaciones para representar correctamente el problema y estructurar la colaboración entre componentes, favoreciendo la reutilización del código .

La figura 1 muestra los principales tipos de relaciones utilizadas en POO, junto con su representación habitual en los diagramas de clases.

Figura 1

Tipos de relaciones en programación orientada a objetos

A continuación, se desarrollan los principales tipos de relaciones entre clases aplicados al ejemplo de acceso seguro a sistemas, donde las entidades principales son: Usuario, Rol, Permiso, Recurso.

8.1 Asociación, agregación, composición, dependencia y herencia

1. Asociación

La asociación es una relación estructural básica entre clases que indica que los objetos de una clase están conectados o interactúan con objetos de otra clase. Esta relación representa una colaboración entre entidades dentro del sistema.

Según , una asociación describe una conexión lógica entre clases que permite a los objetos comunicarse o intercambiar información, sin implicar necesariamente dependencia fuerte o propiedad sobre el ciclo de vida de los objetos.

Ejemplo en control de acceso: En un sistema de ciberseguridad, un usuario tiene uno o varios roles. Esto significa que existe una relación entre la clase Usuario y la clase Rol.

Representación: Usuario tiene Rol

En términos del dominio del problema:

• Un usuario puede tener varios roles.
• Un rol puede ser asignado a múltiples usuarios.

Ejemplo:

Usuario	Rol
Ana	Administrador
Luis	Auditor
María	Usuario

Esta relación se denomina muchos a muchos, ya que varios usuarios pueden compartir un rol.

Justificación de diseño: La asociación permite modelar la asignación de roles de forma flexible. En sistemas de seguridad modernos se utiliza el modelo RBAC (Role-Based Access Control), donde los permisos no se asignan directamente a usuarios, sino a roles.

Esto mejora la administración del sistema porque evita duplicación de permisos, facilita la gestión de accesos, reduce errores de configuración.

Tal como indican , separar responsabilidades mediante relaciones bien definidas mejora la mantenibilidad y escalabilidad del software.

La figura 2 muestra a las clases Usuario y Rol conectadas mediante una relación de asociación denominada “tiene”, lo que indica que un usuario puede tener asociados uno o varios roles dentro del sistema.

Figura 2

Relación de asociación entre las clases Usuario y Rol




2. Agregación

La agregación es un tipo especial de asociación que representa una relación todo–parte, donde una clase contiene a otras pero las partes pueden existir independientemente del todo.

De acuerdo con , la agregación permite modelar estructuras jerárquicas donde un objeto agrupa a otros, sin que estos dependan completamente de su existencia.

Se representa en UML con un rombo vacío.

Ejemplo en control de acceso

Un rol contiene permisos.

Representación: Rol ◇ contiene Permiso

Interpretación:

• Un rol agrupa varios permisos.
• Un permiso puede existir, aunque el rol sea eliminado.
• El mismo permiso puede pertenecer a distintos roles.

Ejemplo:

Rol	Permisos
Administrador	Crear usuario
Administrador	Eliminar usuario
Administrador	Modificar recurso
Auditor	Ver registros
Auditor	Consultar reportes

Justificación de diseño

Esta relación se modela como agregación porque:

• Los permisos son entidades reutilizables
• No dependen exclusivamente de un rol
• Pueden asignarse a múltiples roles

Por ejemplo:

El permiso “leer archivo” podría pertenecer tanto al rol Administrador como al rol Auditor.

Este diseño es fundamental en sistemas de ciberseguridad porque permite reutilizar reglas de acceso y mantener un control centralizado sobre los permisos.

Según Gervais (s. f.), las relaciones de agregación favorecen la modularidad del sistema, permitiendo modificar partes del modelo sin afectar la estructura global.

La figura 3 muestra una relación de agregación que indica que un rol agrupa o contiene permisos, esta estructura permite organizar los privilegios del sistema de manera flexible y escalable, facilitando la administración del control de acceso mediante el modelo control de acceso basado en roles.

Figura 3

Relación de agregación entre Rol y Permiso




3. Composición

La composición es una relación fuerte de tipo todo–parte, donde el objeto contenido depende completamente del objeto contenedor. Esto significa que los componentes solo existen mientras existe el objeto compuesto y no pueden compartirse con otros objetos. Si el objeto principal se elimina, sus componentes también desaparecen.

Guardati Buemo (2007) explica que en la composición existe una dependencia total del ciclo de vida, lo que significa que cuando el objeto contenedor se destruye, los objetos contenidos también desaparecen.

En UML (Unified Modeling Language), esta relación se representa con un rombo negro ubicado en el lado de la clase que representa el todo.

La figura 4 muestra un ejemplo de relación de composición entre la clase Empresa y la clase Empleado. Un objeto Empresa está a su vez compuesto por uno o varios objetos del tipo empleado, el tiempo de vida de los objetos Empleado depende del tiempo de vida de Empresa, ya que si no existe una Empresa no pueden existir sus empleados.

Figura 4

Relación de composición entre las clases Empresa y Empleado




4. Dependencia

La dependencia representa una relación donde una clase utiliza temporalmente a otra para realizar alguna operación.

Según Blanco Fernández (2020), la dependencia indica que un cambio en una clase podría afectar a otra que la utiliza.

No implica propiedad ni asociación permanente.

Ejemplo en control de acceso

El Usuario solicita acceso a un recurso, pero el acceso depende de los permisos asociados a su rol.

Flujo:

Usuario → consulta → Rol

Rol → verifica → Permiso

Permiso → autoriza → Recurso

Este flujo refleja la lógica típica de autorización en un sistema seguro.

Justificación de diseño:

Esta relación muestra el proceso de verificación de acceso.

Por ejemplo:

1. El usuario intenta acceder a un archivo.
2. El sistema identifica los roles del usuario.
3. Se revisan los permisos asociados a esos roles.
4. Se determina si el acceso al recurso está autorizado.

Este proceso representa la interacción dinámica entre objetos dentro del sistema.

Plott y Phillips (2021) señalan que las dependencias permiten modelar colaboraciones entre objetos durante la ejecución del programa.

5. Herencia

La herencia representa una relación jerárquica donde una clase hereda atributos y métodos de otra.

Se conoce como relación “es-un” (is-a).

Ejemplo: EventoLoginFallido es un EventoSeguridad.

Representación en UML: EventoLoginFallido ─────▷ EventoSeguridad

Línea continua con triángulo blanco.

Ejemplo en Java:

public class EventoLoginFallido extends EventoSeguridad {

}

Aquí:

• la clase hija hereda atributos y métodos
• existe una relación estructural fuerte.

Considerando el ejemplo del sistema de acceso seguro, en la tabla 2 se especifica, para cada par de clases el tipo de relación, la multiplicidad y la justificación desde la perspectiva de ciberseguridad. Se define la estructura del control de acceso, garantizando que los permisos no se asignen directamente a los usuarios, sino que se administren a través de roles, lo que facilita la gestión de privilegios, mejora la escalabilidad del sistema y contribuye a aplicar principios fundamentales de seguridad.

Tabla 2

Descripción de las relaciones entre las clases del sistema de acceso seguro

Clase origen	Clase destino	Tipo de relación	Multiplicidad	Justificación en ciberseguridad
Usuario	Rol	Asociación	Un usuario puede tener uno o varios roles (1..*) y un rol puede estar asignado a varios usuarios (0..*)	Permite administrar permisos de manera eficiente sin asignarlos directamente a cada usuario.
Rol	Permiso	Agregación	Un rol puede contener varios permisos (1..*) y un permiso puede pertenecer a varios roles (0..*)	Los roles agrupan permisos relacionados para simplificar la gestión de seguridad.
Permiso	Recurso	Asociación	Un permiso se aplica sobre un recurso específico (1) y un recurso puede tener varios permisos asociados (0..*)	Define qué operaciones pueden realizarse sobre cada recurso protegido.
Usuario	Recurso	Asociación indirecta	La relación se establece a través de roles y permisos	Un usuario accede a recursos únicamente si posee un rol que incluya el permiso correspondiente.

Importancia de definir correctamente las relaciones

Definir correctamente las relaciones entre clases permite:

• representar fielmente el dominio del problema
• mejorar la seguridad del sistema
• facilitar la reutilización del código
• reducir el acoplamiento entre componentes

Además, un diseño adecuado permite aplicar principios de arquitectura segura, como:

• separación de responsabilidades
• control centralizado de permisos
• escalabilidad del sistema

Oviedo Regino (2015) destaca que el modelado orientado a objetos bien estructurado permite traducir correctamente los requerimientos del sistema en estructuras de software coherentes y mantenibles.

8.2 Representación gráfica del diseño

Una vez identificadas las clases del modelo orientado a objetos, es necesario representarlas de forma gráfica para facilitar la comprensión del diseño. Para ello se utiliza el Lenguaje Unificado de Modelado (UML), el cual proporciona diagramas que permiten visualizar la estructura del sistema antes de su implementación .

El diagrama de clases UML es uno de los más utilizados en el diseño orientado a objetos, ya que muestra:

• Las clases del sistema
• Sus atributos
• Sus métodos
• Las relaciones entre clases

Según la literatura sobre programación orientada a objetos, la representación gráfica permite validar el diseño antes de la fase de programación, evitando errores estructurales en la arquitectura del software .

En la figura 5 se observa los diferentes tipos de relaciones identificadas entre clases del sistema de control de acceso seguro.

Figura 5

Relaciones entre clase del sistema de control de acceso seguro

Este diagrama representa el flujo lógico de autorización dentro del sistema.

El proceso funciona de la siguiente manera:

1. Un usuario intenta acceder a un recurso.
2. El sistema consulta los roles asignados al usuario.
3. Cada rol contiene una lista de permisos.
4. El permiso define si una operación específica puede realizarse sobre un recurso protegido.

Este modelo permite implementar mecanismos de seguridad como:

• Autorización basada en roles
• Control de acceso granular
• Auditoría de permisos

Con el propósito de reforzar los conocimientos sobre relaciones entre clase y su representación gráfica, ingresa al siguiente video.