Prevención de Efectos Dominó en Mantenibilidad de Software
Clase 34 de 43 • Curso Profesional de Arquitectura de Software
Contenido del curso
- 2

Atributos de Calidad en Sistemas: Definición y Medición
01:49 - 3

Idoneidad Funcional: Completitud, Exactitud y Pertinencia
02:52 - 4

Eficiencia de Ejecución en Sistemas Informáticos
04:14 - 5

Compatibilidad en Sistemas: Interoperabilidad y Coexistencia
03:49 - 6

Subcaracterísticas de Usabilidad en Desarrollo de Software
08:14 - 7

Confiabilidad de Sistemas: Madurez, Disponibilidad, Resiliencia y Recuperación
05:38 - 8

Seguridad de Usuarios en Desarrollo de Software
04:01 - 9

Subcaracterísticas de Mantenibilidad en Sistemas de Software
06:28 - 10

Medición de Adaptabilidad en Sistemas de Software
02:48 - 11

Relación y Tensión entre Atributos de Calidad en Sistemas de Software
04:04 - 12

Atributos de Calidad en Arquitectura de Software
07:00
- 13

Patrones de Arquitectura Monolítica y Distribuida
02:50 - 14

Modelo Vista Controlador: Separación de Responsabilidades en Aplicaciones
05:38 - 15

Arquitectura de Capas: Diseño y Comunicación entre Niveles
03:14 - 16

Patrones de Arquitectura Orientada a Eventos y Event Sourcing
06:17 - 17

Patrón de Arquitectura MicroKernel y su Implementación en IDEs
01:52 - 18

Arquitectura "Comparte Nada": Optimización y Procesamiento de Datos
02:29 - 19

Patrón de Microservicios en Arquitectura de Software
03:57 - 20

Patrón CQRS para Separación de Consultas y Comandos
03:24 - 21

Arquitectura Hexagonal: Diseño y Aplicación Práctica
04:10 - 22

Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas
05:34 - 23

Patrones de Arquitectura para Aplicaciones Escalables y Modulares
09:22 - 24

Patrones de Arquitectura en Proyectos de Crecimiento Empresarial
07:59
- 25

Diseño de Arquitecturas a Medida: Herramientas y Estrategias
02:18 - 26

Tipos de Conectores en Arquitectura de Software
06:18 - 27

Conectores Asíncronos y Sincrónicos: Implementación y Uso Práctico
03:05 - 28

Diferencias entre Enrutadores y Difusores en Comunicación de Mensajes
01:55 - 29

Conexión de Productores y Consumidores con Colas de Mensajes
03:52 - 30

Framework de Diseño Orientado a Atributos: Escenarios y Tácticas
01:55 - 31

Tácticas para Mejorar la Disponibilidad de Sistemas
05:59 - 32

Tácticas para Mejorar la Disponibilidad del Sistema
04:10 - 33

Tácticas para Mejorar la Mantenibilidad del Software
06:16 - 34

Prevención de Efectos Dominó en Mantenibilidad de Software
12:17 - 35

Estrategias para Mejorar la Eficiencia de Ejecución en Sistemas
09:15 - 36

Tácticas de Seguridad Informática para Detectar, Resistir y Recuperarse de Ataques
09:03 - 37

Estrategias para Mejorar la Capacidad de Prueba de Software
05:14 - 38

Tácticas de Usabilidad en Diseño de Interfaces de Usuario
08:20 - 39

Validación de Arquitectura con ATAM y Métricas de Calidad
06:34 - 40

Diseño de Arquitectura para Startups y Empresas Escalables
10:30
¿Cómo prevenir efectos dominó en sistemas de software?
Los efectos dominó en software ocurren frecuentemente cuando un cambio en un módulo genera la necesidad de cambiar muchos otros, impactando potencialmente todo el sistema. Prevenir estos efectos es crucial para mejorar la mantenibilidad del software y se logra principalmente mediante la ocultación de información y el mantenimiento de interfaces.
¿Por qué ocultar información es clave?
Ocultar información es una táctica que promueve la encapsulación, un principio fundamental en la programación orientada a objetos. Al permitir que un módulo o un objeto oculte ciertos elementos de información, se asegura que los agentes externos dependan de una interfaz estable y no de detalles internos que pueden cambiar.
Por ejemplo, si tienes un módulo que calcula impuestos, puedes ofrecer una interfaz pública que maneje este cálculo de manera consistente, independientemente de cómo los detalles del cálculo interno puedan cambiar a lo largo del tiempo. Esto reduce el riesgo de que los cambios internos afecten a otros módulos que dependen de esta funcionalidad.
¿Cómo mantener una interfaz sólida?
Mantener una interfaz implica definir claramente cómo otros componentes o servicios interactúan con tu módulo a través de un conjunto consistente de funciones o métodos. Al establecer una única interfaz que gestione todas las interacciones necesarias, cualquier cambio interno no afectará a los usuarios externos de tu servicio.
Por ejemplo, si tienes que agregar un paso adicional al proceso de cálculo, mientras la interfaz externa no cambie, los clientes del servicio no se verán afectados. Esto es esencial para lograr un sistema más robusto y fácil de actualizar.
¿Cuál es el rol de los intermediarios en la programación?
Los intermediarios actúan como puentes entre módulos o componentes no compatibles, ayudando a gestionar cambios en interfaces o mensajes sin afectar la estabilidad del sistema. En programación orientada a objetos, patrones como FASAD, PROXY o ADAPTER permiten a los desarrolladores desacoplar componentes y facilitar la evolución del sistema a lo largo del tiempo.
¿Qué es la ley de Demeter y cómo aplica?
La ley de Demeter, también conocida como el principio de menor conocimiento, sugiere que un módulo o componente sólo debe conocer los otros módulos directamente relacionados con él, no las dependencias de sus dependencias. Al limitar estas conexiones, se reduce el riesgo de introducir errores cuando un componente intermedio cambia.
Un ejemplo clásico es cuando gestionas órdenes de compra: en lugar de navegar directamente a través de varios objetos conectados para obtener información del vendedor de un producto, puedes preguntar directamente al objeto principal (en este caso, la orden) por los vendedores, manteniendo así el conocimiento limitado y la interacción modular.
¿Cómo aprovechar el polimorfismo y el reemplazo de componentes?
El polimorfismo permite que los objetos cambien su comportamiento sobre la marcha, dependiendo de su estado o tipo de instancia. Usar esta característica, especialmente común en la programación orientada a objetos, es clave para diferir enlaces y ofrecer flexibilidad en la implementación de funcionalidades.
¿Cuándo utilizar el reemplazo de componentes?
El reemplazo de componentes permite la actualización o sustitución de un módulo sin alterar el sistema. Esto es posible si los componentes se enlazan regularmente en tiempo de carga, permitiendo su renovación sin necesidad de detener el sistema.
Imagina una aplicación que utiliza plugins: puedes actualizar o cambiar un componente simplemente instalando un nuevo plugin que cumpla con la misma interfaz, lo que brinda al sistema la capacidad de adaptarse sin comprometer la estabilidad.
¿Qué beneficio aportan los protocolos a la arquitectura de software?
Adherirse a protocolos de comunicación bien definidos, como JSON o XML, es crucial para que los módulos se comuniquen efectivamente sin importar sus cambios internos. Esto no sólo facilita la mantenibilidad, sino que también asegura que los módulos pueden desplegarse de forma independiente, promoviendo una arquitectura de software modular y eficiente.
¿Cómo implementar archivos de configuración efectivamente?
Utilizar archivos de configuración para definir cómo se conectan diferentes partes del sistema es una práctica común. Estos archivos permiten ajustar la configuración y las interacciones entre módulos de forma dinámica, sin necesidad de recompilar el sistema. Son especialmente útiles en arquitecturas de plugins donde las configuraciones pueden dictar qué extensiones o servicios se utilizan en cada caso, proporcionando flexibilidad y control sobre el flujo de trabajo del software.