Tema
6.1 Interfaces
6.1.1 Contratos de comportamiento
6.1.2 Desacoplamiento mediante interfaces
7. Modelado orientado a objetos
7.1 Identificación de elementos del modelo
7.2 Encapsulamiento y visibilidad
8. Relaciones entre clases
8.1 Asociación, agregación, composición, dependencia y herencia 8.2 Representación gráfica del diseño
9. Principios de diseño orientado a objetos
9.1 Cohesión
9.2 Acoplamiento
10. Desarrollo modular del sistema
10.1 Métodos en clases
10.2 Métodos como representación del comportamiento
10.3 Responsabilidad de los métodos
11. Estructuras de control
1.1 Condicionales
11.2 Bucles
Instrucciones
Propósito de la actividad
Diseñar un sistema completo de gestión segura de accesos, organizando correctamente las clases, sus relaciones y comportamientos, e incorporando el control del flujo del sistema.
Contexto del problema
Una organización necesita implementar un sistema que controle el acceso a sus recursos digitales de forma segura.
Actualmente:
No existen restricciones claras de acceso
No hay diferenciación entre tipos de usuarios
Los permisos no están estructurados
El sistema no controla adecuadamente el flujo de acceso
La arquitectura no permite escalar
Se requiere diseñar un sistema que permita:
Gestionar usuarios
Definir roles
Asignar permisos
Controlar acceso a recursos
Validar solicitudes de acceso
Controlar el flujo del sistema
Escalar sin afectar la estructura base
RETO 2 (integrado en la actividad)
Diseño del Modelo Orientado a objetos y control del flujo del sistema
El estudiante deberá:
Organizar las clases identificadas
Definir relaciones entre ellas
Establecer comportamientos
Diseñar el flujo de ejecución del sistema
Componente teórico
1. Modelado del sistema
Identifique y defina las clases principales:
Mínimo obligatorio:
Usuario
Rol
Permiso
Recurso
GestorAcceso
Para cada clase:
Definir atributos
Definir responsabilidades
2. Interfaces y desacoplamiento
Definir al menos una interfaz (por ejemplo: AccesoControl)
Especificar métodos como contratos
Explicar:
¿Qué obliga la interfaz?
¿Cómo reduce el acoplamiento?
3. Relaciones entre clases
Identifique y justifique:
Asociación
Agregación
Composición
Dependencia
Herencia
4. Encapsulación y visibilidad
Definir niveles de acceso
Justificar decisiones de diseño
Analizar impacto en seguridad
5. Principios de diseño
Analice:
Cohesión:
¿Cada clase cumple una única función?
Acoplamiento:
¿Qué dependencias existen?
¿Cómo reducirlas?
6. Desarrollo modular
Definir métodos por clase
Establecer responsabilidades
Justificar decisiones
7. Control del flujo del sistema
Describa paso a paso el flujo:
Usuario solicita acceso
Sistema valida identidad
Sistema verifica rol
Sistema valida permisos
Sistema concede o deniega acceso
Debe representarse de forma clara (diagrama o explicación estructurada)
8. Uso de estructuras de control
Explique:
Uso de condicionales (validación de permisos)
Uso de bucles (iteración de permisos, roles, etc.)
9. Representación gráfica
Elabore:
Diagrama UML completo
Opcional: diagrama de secuencia del flujo
10. Análisis crítico
Responda:
¿Qué ocurre si no se controla el flujo del sistema?
¿Qué riesgos existen sin una correcta relación entre clases?
¿Cómo afectan el acoplamiento y la cohesión a la seguridad?
¿Por qué este diseño es escalable?
Componente práctico (Java)
Requerimientos técnicos
El sistema debe:
Implementar todas las clases del modelo
Usar interfaces
Aplicar relaciones correctamente
Mantener bajo acoplamiento
Tener alta cohesión
Funcionalidades
Crear usuarios
Asignar roles
Definir permisos
Asociar recursos
Validar acceso a recursos
Controlar flujo de acceso
Uso obligatorio
Condicionales, validación de acceso
Bucles, verificación de permisos
Simulación
En el método main:
Usuario intenta acceder a recurso
Sistema evalúa condiciones
Se muestra resultado
Condición
El sistema debe permitir:
Agregar nuevos roles
Agregar nuevos permisos
Agregar nuevos recursos
sin modificar la estructura base
Tipo de entrega
Archivo comprimido (.zip) con:
Código fuente en Java
Documento de análisis, diseño y modelado
UML actualizado
Video de máximo 5 minutos, donde se pueda mirar la cara del estudiante explicando la funcionalidad del programa y del diseño arquitectónico del software.