Algoritmos y pseudocódigo con un ejemplo BIM

«Revisa los códigos de las puertas». Siete palabras, ninguna decisión cerrada y una confianza conmovedora en que el ordenador sabrá a qué nos referimos. ¿Todas las puertas? ¿De qué planta? ¿Qué código? ¿Qué debería hacer cuando el dato ni siquiera existe? Después nos sorprende que la automatización interprete el encargo de otra manera. Le hemos entregado una intención y esperamos que nos devuelva un procedimiento.

Antes de elegir Python, C# o un grafo con un tamaño incompatible con la pantalla, podemos resolver esa parte. Un algoritmo describe cómo obtener un resultado a partir de unas entradas mediante pasos definidos. El pseudocódigo permite escribir ese recorrido sin casarnos todavía con la sintaxis de un lenguaje. Vamos a utilizar ambos para revisar una pequeña colección ficticia de puertas. Al terminar tendremos una regla que se puede discutir y comprobar antes de convertirla en software. Admito que programar resulta algo menos aventurero cuando uno sabe qué pretende hacer.

La primera instrucción es decidir qué estamos revisando

Supongamos que disponemos de una tabla con identificador de puerta, categoría, nivel y código. La tabla es un ejemplo didáctico; todavía no estamos consultando Revit ni hemos extraído información de un proyecto. Esa separación permite concentrarnos en la regla sin añadir problemas de acceso al modelo, versiones o permisos de edición.

El encargo será revisar las puertas del nivel L01 y comprobar si su código pertenece al catálogo permitido, formado por D01 y D02. La salida será un informe de lectura: no rellenará valores ni modificará elementos. Si aparece un código incorrecto, lo señalará. Determinar cuál debería sustituirlo exigiría otra regla y otra información. Un ordenador puede detectar que X99 no pertenece a un catálogo sin que por ello haya descubierto si la puerta necesita D01 o D02. La imaginación no forma parte del criterio de aceptación.

Ya hemos tomado varias decisiones que estaban escondidas en las siete palabras iniciales. Hemos fijado la selección, el dato que importa, la referencia con la que se compara y el efecto autorizado. También hemos separado revisar de corregir. Parece mucho trabajo para una comprobación tan pequeña, pero esas decisiones tendrán que existir de todas formas. Prefiero encontrarlas aquí que dentro de un botón que ya ha actualizado doscientas puertas.

No hace falta describir cada comportamiento del futuro programa para comenzar. Basta con cerrar el alcance de esta primera operación y reconocer qué queda fuera. Por ejemplo, no comprobaremos dimensiones, normativa, estado de aprobación o pertenencia a grupos. Si mañana interesa añadir alguna de esas condiciones, podremos discutir cómo cambia la selección o la regla. De momento, que el informe responda bien a una pregunta resulta más útil que aparentar respuesta a todas.

Un hueco puede esconder problemas diferentes

Estas serán nuestras entradas. El símbolo «—» indica que el registro no incluye el campo de código; no es un texto almacenado. «Nulo» representa un valor explícitamente nulo. La cadena vacía existe, pero no contiene caracteres.

Puerta	Nivel	Código recibido	Resultado esperado
P001	L01	D01	Cumple el catálogo
P002	L01	Cadena vacía	Incumple: código vacío
P003	L01	Nulo	No evaluable: valor nulo
P004	L01	—	No evaluable: campo ausente
P005	L02	D02	Fuera del alcance
P006	L01	X99	Incumple: fuera del catálogo

Podríamos reunir P002, P003 y P004 bajo una etiqueta «sin código» y terminar antes. También podríamos dejar a quien reciba el informe averiguando qué debe arreglar. En P002 sabemos que el campo existe y contiene un texto vacío: incumple la regla acordada. En P004 falta el propio campo, de modo que quizá haya que revisar la preparación de los datos. P003 declara una ausencia mediante un valor nulo. Para este ejercicio hemos decidido que los dos últimos casos no permiten evaluar el código y deben conservar su motivo.

Esa clasificación es una elección del ejemplo, no una ley universal sobre todos los parámetros BIM. Otro proceso podría decidir que un nulo incumple directamente un requisito de información. Lo importante es declararlo y aplicarlo de manera consistente. Si la política cambia, cambiará la regla; no debería cambiar el significado de una celda a mitad de la ejecución porque alguien quiso que el informe tuviera menos categorías.

Además, el código incorrecto P006 aporta información que una celda vacía no ofrece: alguien ha enviado X99. Mantener ese valor permite investigar si se utilizó otro catálogo, si hay un error de escritura o si la referencia acordada está incompleta. Sustituirlo automáticamente por una opción admisible destruiría precisamente la evidencia que necesitamos para decidir. La limpieza visual de la tabla tiene un talento considerable para ocultar problemas.

Escribir el recorrido antes de traducirlo

El pseudocódigo que sigue utiliza palabras elegidas para que podamos leer el proceso. No es Python traducido al castellano ni un archivo que haya que ejecutar. Su utilidad es hacer visible el orden: comprobar la entrada, seleccionar, distinguir situaciones y registrar un resultado. Después podremos expresar ese mismo recorrido con las construcciones que ofrezca el lenguaje elegido.

				
					ENTRADAS
    colección de puertas
    nivel objetivo = L01
    catálogo permitido = D01, D02

COMPROBAR que cada registro tiene identificador único, categoría y nivel
SI la entrada no permite identificar o seleccionar los registros
    INFORMAR del problema de entrada y detener esta revisión

PARA CADA registro de la colección
    SI no es una puerta del nivel objetivo
        REGISTRAR fuera del alcance
    EN OTRO CASO
        SI falta el campo código
            REGISTRAR no evaluable: campo ausente
        SI NO, SI el código es nulo
            REGISTRAR no evaluable: valor nulo
        SI NO, SI el código no es texto
            REGISTRAR no evaluable: tipo inesperado
        SI NO, SI el código es texto vacío
            REGISTRAR incumple: código vacío
        SI NO, SI el código pertenece al catálogo permitido
            REGISTRAR cumple
        SI NO
            REGISTRAR incumple: fuera del catálogo

DEVOLVER resultados con identificador, estado, motivo y valor recibido

La comprobación inicial protege algo elemental: saber a qué registro pertenece cada resultado y si podemos seleccionarlo. Si dos puertas llevan el mismo identificador o un registro carece de nivel, no fingiremos que la revisión completa es válida. Hemos elegido detenerla y explicar el problema de entrada. Un sistema más elaborado podría aislar registros inválidos y continuar con el resto, pero tendría que mostrar qué parte ha revisado y cuál ha excluido. No es un detalle que deba decidir silenciosamente la primera instrucción que encuentre un valor extraño.

Dentro del recorrido, cada puerta seleccionada termina en una sola rama. El orden permite preguntar si el campo existe antes de intentar interpretar su contenido. La rama del tipo inesperado contempla una entrada distinta de las seis iniciales, por ejemplo un número donde esperábamos texto. No intentará convertirlo a código por su cuenta: hacerlo exigiría acordar otra transformación.

Fíjate también en lo que no hace este algoritmo. No cambia el catálogo, no deduce niveles, no borra resultados incómodos y no decide correcciones. El último paso devuelve lo que permite revisar el trabajo. Un procedimiento puede tener muchas instrucciones y seguir siendo incomprensible si sus efectos están mal definidos; aquí la longitud del bloque sirve para mostrar las decisiones, no para demostrar que somos capaces de escribir mucho.

Seguir una puerta hasta su resultado

Recorramos P004. Tiene identificador, categoría y nivel, así que supera la comprobación inicial y entra en la selección L01. Al llegar al código, el campo no existe. El procedimiento registra «no evaluable: campo ausente» y termina la clasificación de esa puerta. No necesita preguntar después si el código pertenece a D01/D02: no dispone de un valor que comparar.

P006 recorre otro camino. El campo está presente, su valor es texto y no está vacío. Llega hasta la comparación con el catálogo y obtiene un incumplimiento. Ambas puertas requieren atención, pero ahora el informe permite distinguir por qué. En una tendremos que recuperar o preparar un dato; en la otra podremos contrastar el valor recibido con la referencia. Acabamos de ahorrarle al siguiente humano una investigación que no aportaba nada al proyecto. Una aplicación bastante digna de la tecnología, por una vez.

Al terminar las seis entradas deben aparecer una puerta conforme, dos incumplimientos, dos casos no evaluables y una exclusión por alcance. Los resultados suman seis. Entre las cinco puertas seleccionadas hay una conforme, dos que incumplen y dos que no hemos podido evaluar. Mostrar únicamente «dos errores» ocultaría una parte importante de lo ocurrido; mostrar «cuatro errores» borraría la distinción que acabamos de construir.

Podemos comprobar esas cuentas sin ejecutar código. La tabla de resultados esperados actúa como referencia independiente para seguir el pseudocódigo. Cuando llegue la implementación, la comparación no consistirá en leer un mensaje «terminado»: habrá que verificar que cada identificador tiene el estado previsto. Un programa que se ejecuta sin lanzar excepciones también puede aplicar una regla equivocada con perfecta educación.

El lenguaje llega cuando la decisión ya se entiende

Al traducir el recorrido, una colección, una condición y una repetición necesitarán formas concretas. Python utiliza construcciones como if y for, descritas en su guía oficial de control de flujo. C# ofrece sus propias instrucciones y tipos. La elección influirá en cómo se representa un registro y cómo se comprueba un campo ausente; no debería cambiar sin explicación qué significan nuestros resultados.

Por eso no comenzaría buscando «el código para revisar puertas». Primero conservaría esta tabla, el catálogo y la regla. Después elegiría el entorno y prepararía una implementación pequeña capaz de reproducirlos. En artículos posteriores veremos variables, colecciones, condiciones y funciones. Aquí ya hemos hecho una parte del trabajo que esos recursos expresarán: decidir qué entra, qué ocurre con cada caso y qué debe salir.

También hemos separado la regla del origen. Hoy las puertas están en una tabla ficticia. Más adelante podrían llegar de un CSV, un IFC o una consulta a Revit, y cada origen necesitaría su lectura y sus comprobaciones. Mantener una lógica reconocible permite preguntar si un fallo está en la extracción, en la selección o en la clasificación. Mezclar las tres cosas desde el primer intento convierte cualquier resultado extraño en una expedición al archivo entero.

No buscaría una especificación eterna. Si el catálogo cambia o el equipo decide que los nulos deben contar como incumplimientos, habrá que revisar el procedimiento y sus resultados esperados. Lo que sí exigiría es que ese cambio sea consciente. Tener la regla escrita permite discutirlo sin abrir un entorno de desarrollo y sin atribuir al programa una autoridad que pertenece al proyecto.

Prueba ahora una modificación pequeña: cambia el nivel objetivo de L01 a L02. Debería revisarse P005 y las otras cinco puertas quedarían fuera del alcance. Si no puedes anticipar ese resultado recorriendo tus instrucciones, todavía falta concretar algo. Resolverlo sobre seis filas cuesta poco. Descubrirlo después de generar el informe de una entrega completa proporciona bastante más entretenimiento del que suelo recomendar.