Grafos Causa-Efecto

¿Qué Es Cause-Effect Graphing? #

Cause-effect graphing es una técnica sistemática que traduce especificaciones en lenguaje natural a un grafo de lógica booleana, que luego se convierte en una tabla de decisión. Conecta requerimientos ambiguos con test cases precisos.

¿Por Qué Usar Cause-Effect Graphing? #

Las tablas de decisión son poderosas pero tienen una debilidad: con muchas condiciones, obtienes 2^N reglas, la mayoría de las cuales pueden ser imposibles o redundantes. Cause-effect graphing resuelve esto modelando las relaciones lógicas y restricciones entre inputs, generando solo combinaciones significativas.

Conceptos Clave #

• Causa: Una condición de input o estímulo (lado izquierdo del grafo)
• Efecto: Un output o respuesta del sistema (lado derecho del grafo)
• Operadores booleanos: AND, OR, NOT — conectando causas con efectos
• Restricciones: Reglas que limitan qué combinaciones de causas son posibles

El Proceso #

Operadores Booleanos en Grafos #

Identidad: Si la causa C1 es verdadera, el efecto E1 es verdadero.

C1 ────── E1

NOT (negación): Si la causa C1 es verdadera, el efecto E1 es falso.

C1 ──~──── E1

AND: El efecto E1 es verdadero solo cuando C1 Y C2 son verdaderos.

C1 ──┐
     ├─ AND ── E1
C2 ──┘

OR: El efecto E1 es verdadero cuando C1 O C2 (o ambos) son verdaderos.

C1 ──┐
     ├─ OR ── E1
C2 ──┘

Ejemplo: Sistema de Login #

Especificación:

• Si el username es válido Y el password es correcto, conceder acceso
• Si el username es válido Y el password es incorrecto, mostrar “password incorrecto”
• Si el username es inválido, mostrar “usuario no encontrado”

Causas:

• C1: Username es válido
• C2: Password es correcto

Efectos:

• E1: Conceder acceso
• E2: Mostrar “password incorrecto”
• E3: Mostrar “usuario no encontrado”

Grafo:

C1 ──┐
     ├─ AND ── E1 (conceder acceso)
C2 ──┘

C1 ──┐
     ├─ AND ── E2 (password incorrecto)
~C2 ─┘

~C1 ────────── E3 (usuario no encontrado)

Restricciones Entre Causas #

Los inputs del mundo real frecuentemente tienen dependencias. Las restricciones las modelan:

Ejemplo: Selección de método de pago

• C1: Tarjeta de crédito seleccionada
• C2: PayPal seleccionado
• C3: Transferencia bancaria seleccionada

Restricción: O (One-and-only-one) — exactamente un método de pago debe estar seleccionado.

Esto elimina combinaciones donde 0 o 2+ métodos están seleccionados, reduciendo drásticamente la tabla de decisión.

Convirtiendo a Tabla de Decisión #

Para el ejemplo de login:

Nota: Cuando C1 es falso (R3), C2 es irrelevante (marcado -) porque el sistema muestra “usuario no encontrado” sin importar el password.

Cause-Effect Graphing Avanzado #

Ejemplo Complejo: Sistema de Descuentos de Órdenes #

Especificación:

• Causa C1: El cliente es miembro VIP
• Causa C2: Total de orden > $100
• Causa C3: Código de cupón aplicado
• Restricción: C1 y C3 son mutuamente excluyentes (E) — miembros VIP no pueden usar cupones
• Efecto E1: 10% descuento (VIP)
• Efecto E2: 15% descuento (VIP + orden > $100)
• Efecto E3: Descuento de cupón aplicado
• Efecto E4: Sin descuento

Construcción del grafo:

C1 AND C2 ──── E2 (15% VIP + volumen)
C1 AND ~C2 ── E1 (10% solo VIP)
~C1 AND C3 ── E3 (descuento de cupón)
~C1 AND ~C3 ─ E4 (sin descuento)

Restricción E entre C1 y C3

Tabla de decisión después de aplicar restricción:

C3 se fuerza a falso cuando C1 es verdadero por la restricción Exclusive.

Sin la restricción, tendríamos 2^3 = 8 reglas. Con ella, solo tenemos 4 combinaciones significativas.

Manejo de Especificaciones Grandes #

Para sistemas complejos con muchas causas y efectos:

1. Descomponer. Dividir la especificación en subsecciones independientes, cada una con su propio grafo.
2. Encadenar efectos. Un efecto de un grafo puede convertirse en causa de otro.
3. Numerar sistemáticamente. Usar C1-Cn para causas, E1-En para efectos, consistente con la trazabilidad de requerimientos.

Errores Comunes #

1. Negaciones faltantes. No olvides modelar qué sucede cuando una causa es falsa.
2. Ignorar restricciones. Sin restricciones, generarás test cases imposibles.
3. Confundir causas con efectos. Las causas son inputs que controlas; los efectos son outputs que observas.

Ejercicio: Construye un Grafo Causa-Efecto #

Escenario: Un sistema de carga de archivos tiene estas reglas:

• C1: Tamaño del archivo <= 10MB
• C2: Tipo de archivo permitido (jpg, png, pdf)
• C3: Usuario autenticado
• C4: Cuota de almacenamiento no excedida

Reglas:

• Si C3 es falso → E1: “Por favor inicia sesión”
• Si C3 AND C1 AND C2 AND C4 → E2: “Carga exitosa”
• Si C3 AND NOT C1 → E3: “Archivo demasiado grande”
• Si C3 AND NOT C2 → E4: “Tipo de archivo no permitido”
• Si C3 AND C1 AND C2 AND NOT C4 → E5: “Almacenamiento lleno”

Restricción: R (Requires) — C1, C2, C4 requieren C3

Tarea: Dibuja el grafo, aplica restricciones, construye la tabla de decisión y cuenta los test cases.

Tips de Profesional #

• Usa cause-effect graphing cuando las decision tables se vuelven muy grandes. Si tienes 6+ condiciones, una tabla completa tiene 64+ reglas. Las restricciones pueden reducir esto dramáticamente.
• Combínalo con revisión de requerimientos. Construir el grafo frecuentemente revela ambigüedades, contradicciones y vacíos en la especificación.
• Documenta el grafo. La representación visual es excelente para comunicar la lógica de testing a desarrolladores y product owners.
• Aplica orden de prioridad de errores. En sistemas reales, las validaciones tienen prioridad (auth primero, luego validación de input, luego reglas de negocio).