Qué es un modelo y para qué sirve
Seguí leyendo
Enterate del próximo post
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
La primera decisión de la Tienda Alfar, en qué momento se aparta una pieza, se pudo tomar mirando una sola regla del negocio. Las decisiones siguientes no van a ser tan locales: van a tocar varias partes a la vez, y para razonar sobre varias partes a la vez hace falta poder ver el sistema entero sin ahogarse en sus detalles. Esa es la función de un modelo, y también su riesgo, porque un modelo solo sirve si alguien decidió qué dejarle afuera.
Un modelo es una simplificación de algo con un propósito concreto. Las dos partes de la definición importan por igual. Sin simplificación, el modelo sería el sistema mismo. Sin propósito, no hay criterio para decidir qué se simplifica, y el resultado es una versión achicada del sistema que no responde ninguna pregunta en particular.
El estadístico George Box lo dejó escrito en dos frases que se citan mucho más allá de la estadística. En 1976 sostuvo que todos los modelos están equivocados, y que por eso no tiene sentido buscar el correcto a fuerza de agregarle detalle. En 1987, junto con Norman Draper, lo completó: todos los modelos están equivocados, pero algunos son útiles. La primera mitad no es una queja sino una descripción: un modelo omite cosas por definición. La segunda mitad pone el criterio. Un modelo no se juzga por cuánto se parece al sistema, sino por si sirve para la tarea para la que se hizo.
El ejemplo clásico es el plano de una red de subterráneos. Deforma las distancias, endereza las curvas y separa estaciones que en la superficie están a una cuadra. Como mapa de la ciudad es pésimo. Como herramienta para saber dónde combinar y cuántas estaciones faltan, es mejor que cualquier mapa fiel, justamente porque eliminó todo lo que no servía para esa pregunta.
En software, los modelos se usan sobre todo para dos cosas distintas. Un modelo para comunicar existe para que varias personas compartan la misma imagen del sistema: tiene que entenderse rápido, por alguien que no lo dibujó. Un modelo para razonar existe para descubrir algo que no se veía, por ejemplo una transición de estado imposible o un paso que nadie espera: tiene que ser preciso en lo que muestra, aunque sea difícil de leer. Las dos funciones tiran para lados opuestos, y un diagrama que intenta mostrarlo todo suele fallar en las dos: es demasiado denso para comunicar y demasiado mezclado para razonar porque mezcla preguntas que no tienen nada que ver entre sí.
La salida a ese problema tiene nombre desde hace tres décadas. Philippe Kruchten propuso en 1995 el modelo de vistas 4+1: describir la arquitectura de un sistema con varias vistas, cada una pensada para un tipo de interesado y una clase de preocupación (la organización lógica, los procesos en ejecución, la organización del código, el despliegue físico) más un conjunto de escenarios que las atraviesa a todas. La idea que sobrevivió no es la cantidad exacta de vistas sino el principio: ningún diagrama único describe un sistema, y cada vista es un modelo distinto con su propio criterio de qué dejar afuera. Hoy existe una notación muy difundida que lleva esa idea a la práctica con niveles de acercamiento, y la serie la desarrolla más adelante; por ahora alcanza con el principio.
El costo de trabajar con modelos también conviene decirlo. Un modelo envejece: el sistema cambia y el dibujo no, salvo que alguien lo mantenga. Y un modelo convence: una caja bien dibujada transmite una seguridad que la decisión detrás de ella puede no tener. Las dos cosas empujan a modelar poco y a propósito, no a dibujar todo lo que se pueda.
La decisión del post anterior habla de iniciar un pago y de confirmarlo más tarde, pero no dice quién participa de esa conversación. Antes de seguir tomando decisiones conviene tener una imagen compartida del sistema, aunque sea mínima. La pregunta concreta que tiene que responder el primer modelo de Alfar es esta: quiénes intervienen en una compra y qué se dicen.
Primero, en prosa. Una persona entra a la tienda, mira las piezas disponibles y elige una. Al iniciar el pago, la tienda aparta la pieza y le pide el cobro a una pasarela de pagos; la pasarela cobra y, más tarde, le avisa a la tienda si el pago salió bien, y con ese aviso la tienda confirma el pedido o libera la pieza.
El párrafo es correcto, pero tiene una ambigüedad que pasa desapercibida: no dice si la pasarela es parte de la tienda o algo de afuera. Una persona puede leerlo imaginando que la tienda tiene un formulario donde se escriben los datos de la tarjeta, y otra imaginando que la tienda redirige a un sitio ajeno. Las dos lecturas son compatibles con el texto, y llevan a sistemas muy distintos.
El mismo sistema, ahora como boceto. Antes del boceto va un archivo de estilo, que todos los diagramas de la serie van a incluir para verse igual: colores neutros y un solo acento naranja para lo que cada diagrama destaca.
skinparam defaultFontName "DejaVu Sans"
skinparam defaultFontSize 15
skinparam shadowing false
skinparam roundCorner 10
skinparam backgroundColor #ffffff
skinparam ArrowColor #57534e
skinparam ArrowFontColor #44403c
skinparam ArrowFontSize 13
skinparam rectangle {
BackgroundColor #fafaf9
BorderColor #78716c
FontColor #1c1917
}
skinparam rectangle<<destacado>> {
BackgroundColor #fff7ed
BorderColor #ea580c
BorderThickness 2
}
skinparam actor {
BackgroundColor #fafaf9
BorderColor #78716c
}
hide stereotype@startuml boceto-tienda
!include estilo.iuml
actor "Comprador" as comprador
rectangle "<b>Tienda Alfar</b>\n\nmuestra las piezas,\naparta y registra pedidos" as tienda <<destacado>>
rectangle "<b>Pasarela de pagos</b>\n\nexterna: cobra y\nconfirma después" as pasarela
comprador -down-> tienda : elige una pieza\ne inicia el pago
tienda -right-> pasarela : pide el cobro
pasarela -left-> tienda : avisa el resultado
@enduml
Tres cajas y tres flechas. Lo interesante del boceto está en lo que no tiene. No aparece el transportista que lleva las piezas, ni el servicio de correo que avisa a quien compra, ni la persona del taller que carga las piezas nuevas. No aparece ninguna base de datos, ni el plazo durante el cual una pieza queda apartada, ni ninguna división interna de la tienda. Todo eso queda afuera a propósito: la pregunta del modelo era quién interviene en una compra, y ninguno de esos elementos cambia la respuesta. El día en que la pregunta sea cómo llega una pieza a destino, el transportista será el centro de otro modelo distinto.
La decisión menos obvia del boceto no es lo que se omitió, sino dónde quedó la pasarela: en una caja propia, fuera de la tienda, con la palabra "externa". El párrafo en prosa permitía no decidirlo. El dibujo no lo permite, porque una caja está adentro o afuera de otra, y no existe una forma de trazarla que quede a mitad de camino. Al dibujar, la ambigüedad del párrafo se convirtió en una decisión, y esa decisión no es de notación: cambia qué tiene que construir la tienda.
El archivo de decisiones suma su segunda entrada. La primera queda como estaba.
# Decisiones de la Tienda Alfar
## 1. En qué momento se aparta una pieza
Una pieza se aparta para quien inicia el pago, no para quien lo confirma.
Mientras está apartada, nadie más puede comprarla. Si el pago no se
confirma dentro de un plazo, la pieza vuelve a estar disponible.
El plazo todavía no está decidido.
Lo que se paga: una pieza puede quedar bloqueada durante ese plazo por
una compra que no se completa.
## 2. Quién cobra
La tienda no recibe ni guarda datos de tarjetas. El cobro lo hace una
pasarela de pagos externa, y la tienda solo se entera del resultado,
que llega después y por separado.
Lo que se paga: una comisión por cada venta, una dependencia de un
tercero que, si no responde, deja a la tienda sin poder vender, y una
confirmación que nunca es inmediata.La alternativa descartada es que la tienda reciba los datos de la tarjeta en su propio formulario y los procese directamente con un banco o un procesador. Tiene ventajas reales: la comisión puede ser menor, la experiencia de compra no sale nunca del sitio y la tienda controla todo el recorrido. Pero quien recibe datos de tarjetas queda alcanzado por PCI DSS, la norma de seguridad que fijan las marcas de tarjetas, con controles, auditorías y responsabilidades que un taller de cerámica con una sola persona técnica no puede sostener.
La opción elegida tiene costos que no son solo la comisión. Si la pasarela está caída, la tienda no puede vender, aunque todo lo demás funcione. Cambiar de pasarela más adelante no es gratuito, porque la conversación con ella, sus avisos y sus estados quedan repartidos en el código de compra. Y la confirmación asíncrona, la flecha que vuelve en el boceto, es la que obligó a pensar la primera decisión: si el cobro respondiera en el mismo instante, el plazo de apartado casi no haría falta. Las dos entradas del archivo están conectadas, y el boceto lo deja a la vista mejor que cualquiera de los dos párrafos por separado.
La condición de reversión también queda escrita, aunque esté lejos: si el volumen de ventas llegara a un punto en que la suma de comisiones superara el costo de certificarse y operar con datos de tarjetas, convendría revisar la decisión. Para un taller que vende piezas únicas, ese punto no está en el horizonte. Cambiar una pasarela por otra, en cambio, no revierte la decisión: la confirma con otro proveedor.
Un modelo es una simplificación con un propósito. Lo que deja afuera es tan deliberado como lo que muestra, y a veces dibujarlo obliga a tomar una decisión que la prosa permitía esquivar.
El boceto respondió quién interviene en una compra, pero no dice nada de cuánta gente va a comprar al mismo tiempo, quién va a mantener el sistema ni cuánto puede costar operarlo. Esas preguntas no cambian ninguna caja del dibujo y, sin embargo, son las que más pesan sobre la forma que termina teniendo un sistema. El próximo post trata de eso: los requisitos, los atributos de calidad y las restricciones, y por qué los primeros casi nunca son los que deciden la arquitectura.