Cómo un grafo de dependencias descubre llamadas ocultas

Un grafo de dependencias solo es tan honesto como el límite usado para construirlo. Analizar un repositorio cada vez puede dar un resultado preciso, completo y casi inútil: las llamadas que deciden si una reescritura conserva el comportamiento suelen cruzar un planificador, una base de datos, un archivo generado, un copybook compartido o un protocolo que no pertenece a ningún repositorio.

Leer todo el árbol en conjunto cambia la unidad de análisis. Un programa COBOL y su JCL dejan de ser elementos separados. Un trabajo RPG, una envoltura CL y una tabla escrita por una importación nocturna forman una ruta de ejecución. El grafo conecta pruebas de distintos lenguajes y marca dónde terminan. Esto importa: un grafo creíble distingue una arista demostrada de otra plausible, en lugar de convertir en certeza cualquier nombre coincidente.

He visto análisis por repositorio producir diagramas tranquilizadores mientras la ruta de producción pasaba por código ausente del dibujo. El analizador funcionaba. Su pregunta era demasiado pequeña.

Los límites del repositorio son administrativos

Un grafo por repositorio describe cómo los archivos fuente se refieren entre sí dentro de un contenedor elegido. Un grafo del sistema describe cómo se mueve el comportamiento por todos los artefactos capaces de influir en una ejecución. Son productos distintos, y confundirlos conduce a alcances de migración incompletos.

Los repositorios suelen reflejar propiedad de equipos, permisos, entregas de proveedores o una migración antigua. El comportamiento en ejecución no respeta esas decisiones. Una petición web puede empezar en Classic ASP, invocar un componente COM creado con VB6, llamar a un procedimiento almacenado guardado en otro repositorio y dejar trabajo para un programa COBOL planificado. Cada repositorio puede entenderse bien mientras la transacción de negocio completa sigue oculta.

La palabra dependencia también exige precisión. Una referencia textual demuestra que un artefacto nombra a otro. Una dependencia invocable significa que el destino puede recibir el control bajo alguna condición. Una dependencia de comportamiento significa que cambiar el destino puede alterar un resultado observado por usuarios o sistemas posteriores. Las herramientas locales suelen reducir las tres a una línea. En una reescritura, ese atajo genera falsa confianza y trabajo inútil.

El grafo práctico necesita más que archivos y funciones como nodos. Debe incluir trabajos, objetos de base de datos, destinos de mensajes, artefactos generados, programas externos, esquemas, pantallas, informes y entradas de configuración cuando participan en el comportamiento. Cada arista debe explicar por qué existe: llamada directa, selección dinámica, flujo de datos, planificación, generación o nombre sin resolver. Con esa prueba, un ingeniero puede cuestionar el grafo en vez de limitarse a mirarlo.

Este modelo amplio no obliga a meterlo todo en un repositorio. Mantenga los repositorios y cambie el límite del análisis. El límite correcto reúne los artefactos que pueden influir en el comportamiento reescrito, aunque la propiedad y el despliegue los separen.

Las aristas entre lenguajes usan mecanismos corrientes

Las llamadas importantes rara vez se anuncian como arquitectura multilenguaje. Aparecen como mecanismos habituales: una cadena de comando, un procedimiento almacenado, un paso de trabajo, un símbolo exportado, un destino de cola o un nombre de archivo para el siguiente proceso. Un analizador de lenguaje ve sintaxis. El grafo del sistema debe interpretar lo que esa sintaxis provoca en otro sitio.

Considere un paso JCL con PGM=BILLRUN. La arista no termina en BILLRUN. El análisis debe resolver el programa mediante las bibliotecas de carga pertinentes, enlazarlo al inventario fuente o binario y conservar la incertidumbre si hay varios candidatos. Dentro del programa, un CALL WS-PROGRAM de COBOL no es una llamada estática normal porque el destino viene de datos. El valor puede proceder de un copybook, un archivo de parámetros o una lectura anterior de la base.

El mismo patrón aparece en otras plataformas. CL puede enviar un programa RPG a una cola batch. VB6 puede crear una clase COM usando una cadena del registro o de configuración. ColdFusion puede llamar a un procedimiento implementado en PL/SQL. Un monolito PHP puede escribir un archivo de control que un demonio Perl interpreta como instrucción. No hace falta una reflexión exótica. Las aristas desaparecen porque cada analizador se detiene en el límite de su lenguaje o repositorio.

Un artefacto intermedio útil deja visible y revisable la unión. Un archivo de aristas separado por tabuladores puede llevar la prueba mínima:

source	target	mechanism	evidence
JCL:AR_CLOSE:STEP20	COBOL:BILLRUN	program-load	PGM=BILLRUN
COBOL:BILLRUN:PARA140	DB2:SP_POST_LEDGER	dynamic-sql	value-set:POST_LEDGER
DB2:SP_POST_LEDGER	TABLE:GL_ENTRY	write	INSERT INTO GL_ENTRY
CL:ENDDAY:CMD7	RPG:RECONCILE	submit-job	CALL PGM(RECONCILE)

Este archivo no es el grafo final. Es un contrato entre extracción y revisión. Cada fila declara origen, destino, mecanismo y prueba. Si la herramienta no puede llenar la última columna, no debe dibujar en silencio una arista firme.

Los nombres se resuelven al reunir las pruebas

Las llamadas dinámicas no son necesariamente incognoscibles. Muchas se resuelven cuando el análisis reúne asignaciones, configuración, metadatos de compilación y muestras de ejecución de todo el árbol. El error consiste en tratar un punto de llamada no literal como un callejón sin salida antes de buscar los valores que pueden alcanzarlo.

Suponga que un párrafo COBOL llama a WS-NEXT-PGM. Un repositorio contiene la llamada, pero no la asignación. JCL en otro repositorio pasa un parámetro simbólico. Un copybook compartido define el ancho del campo. Una exportación de la tabla de control contiene los valores desplegados. Por separado, la llamada no se resuelve. En conjunto, el analizador deriva candidatos, rechaza los valores que no caben y enlaza los restantes al inventario de programas.

La resolución debe seguir basada en pruebas. En las revisiones uso cuatro estados de arista: confirmada por sintaxis, derivada de valores limitados, observada en tráfico grabado y sin resolver. El nombre de los estados importa menos que mantenerlos separados. Un candidato derivado ayuda a fijar el alcance, pero no demuestra que producción recorra esa ruta. Una llamada observada demuestra que apareció en la muestra, no que no existan otros destinos.

Aquí también falla la coincidencia ingenua de nombres. POST, UPDATE o CLOSE pueden existir en docenas de espacios. Una coincidencia solo gana credibilidad después de aplicar reglas de resolución de la plataforma, límites del campo, convención de llamada, contexto de despliegue y asignaciones alcanzables. El análisis global aporta más pruebas, pero también necesita una desambiguación más estricta. Más entradas sin reglas solo producen un grafo erróneo más denso.

El código generado merece el mismo tratamiento. Generador, plantillas, entradas y artefacto emitido forman una cadena. Si solo se analiza la salida, el grafo confunde una consecuencia con la autoridad. Si solo se analizan plantillas, pierde los nombres concretos creados para un despliegue. Conserve ambos y marque la arista de generación para rastrear un cambio hasta lo que volverá a crear el archivo.

El movimiento de datos suele ser la llamada que falta

Un grafo de llamadas no explica muchos sistemas heredados porque los datos realizan el traspaso. Un proceso escribe una fila, un archivo o una entrada de spool; otro lo interpreta después. Ninguna función llama directamente a la siguiente, pero el primer programa controla lo que hará el segundo. Para la paridad de comportamiento, eso es una dependencia.

El procesamiento nocturno lo muestra con claridad. Una transacción en línea escribe un estado en una tabla. Un planificador inicia un trabajo batch al cierre. El trabajo selecciona filas con ese estado, crea un archivo de ancho fijo y otro programa lo importa en el mayor. Los grafos locales muestran cuatro islas. El grafo del sistema muestra una transacción con un predicado, un horario, un formato de registro y una regla de nombre de archivo.

Tratar cada tabla compartida como una dependencia crearía ruido. El grafo necesita sensibilidad a operaciones y campos. Un escritor que cambia customer.last_seen quizá no influya en un lector que filtra customer.credit_hold. Un escritor que cambia el campo de estado filtrado sí influye. Dos programas que tocan el mismo archivo tampoco están conectados si usan tipos de registro distintos.

Una arista de datos útil registra como mínimo el objeto, la operación, los campos o formato relevantes y el predicado que activa al lector. Para archivos batch, incluya productor, consumidor, regla de nombre, codificación, delimitador o posiciones y totales de control verificados. En procedimientos almacenados, distinga la llamada al procedimiento de la lectura de tablas que este cambia. Estos detalles deciden dónde puede introducirse con seguridad un nuevo esquema o una frontera de servicio.

La pregunta incómoda es si esto vuelve inmanejable el grafo. Sí, cuando cualquier coincidencia de datos se convierte en arista firme. Sigue siendo útil si ofrece vistas filtradas: transferencia de control, influencia de datos, planificación, generación e incertidumbre externa. El modelo unificado debe conservar los tipos, no aplanarlos en una masa de flechas.

Incluso un árbol completo tiene un exterior

Leer todos los archivos suministrados no da conocimiento completo del sistema en ejecución. Da conocimiento completo de ese conjunto de pruebas. Planificadores externos, triggers, órdenes de operador, entradas de registro, rutas de middleware, binarios de terceros y configuración de producción pueden introducir comportamiento que el análisis fuente no demuestra.

Muchos informes de modernización se vuelven deshonestos aquí. Llaman completo a un grafo cuando solo terminó el análisis. Completar un escaneo no dice si la entrada cubría el entorno de ejecución. Un buen resultado incluye una frontera explícita: nodos y aristas que apuntan fuera de las pruebas, con el motivo por el que siguen abiertos.

Convierta esa frontera en algo concreto. Exporte nombres de programa sin resolver, objetos externos, destinos de cola, rutas y claves de configuración a una tabla de revisión. Asigne a cada elemento una persona y un estado, como pendiente de entrega, externo verificado, retirado o desconocido. No borre un nodo porque nadie lo reconozca. Los sistemas antiguos contienen código inactivo, pero reconocerlo no demuestra su alcance.

Las observaciones en ejecución ayudan si nadie las considera exhaustivas. El tráfico grabado confirma que una ruta ocurrió y aporta valores para destinos dinámicos. No prueba que una rama rara de fin de año, un procedimiento de recuperación o una orden exclusiva de operador nunca se ejecute. La prueba estática aporta estructura posible; la prueba de ejecución, comportamiento observado. Su coincidencia es fuerte y su desacuerdo merece investigación.

El grafo debe responder dos preguntas por separado: qué pueden causar los artefactos suministrados y qué causó realmente la carga grabada. Un alcance basado solo en lo primero puede conservar rutas muertas para siempre. Uno basado solo en lo segundo puede borrar una excepción válida. Mantenga ambas vistas y haga visible la decisión.

Una arista omitida puede arruinar una buena reescritura

Una dependencia omitida suele fallar lejos del código que faltaba. Ese retraso explica que los equipos subestimen los límites durante la planificación y culpen a las pruebas cuando la puesta en producción revela el sistema real.

Pensemos en un cierre mensual repartido entre cuatro repositorios. Un programa RPG marca cuentas aptas y llama a una envoltura CL. Esta envía un trabajo con un nombre leído de un área de datos. JCL en otro host ejecuta el programa COBOL elegido. Este escribe un archivo de excepciones de ancho fijo, y una aplicación VB6 permite al operador aprobar registros antes de que PL/SQL los contabilice. Cada repositorio tiene pruebas y cada equipo entiende su tramo.

El análisis local encuentra la llamada RPG a CL y las escrituras PL/SQL. Omite el programa enviado porque su nombre es un dato, el JCL porque vive en otro lugar y la aprobación de escritorio porque el archivo es la interfaz. La reescritura reemplaza el primer tramo con un servicio y reproduce sus cambios de base de datos. Las pruebas con cuentas normales pasan.

Al cerrar, las excepciones quedan sin contabilizar. El nuevo servicio no emite el archivo porque nadie incluyó esa salida en su contrato. La aplicación de escritorio no muestra nada, el operador no puede aprobar y ninguna excepción llega al procedimiento. El defecto parece de interfaz o base de datos, pero nació cuando el análisis dibujó el servicio alrededor de un repositorio.

Un grafo global habría conectado llamada, trabajo enviado, programa planificado, producción de archivo, acción del operador y procedimiento almacenado. También habría marcado el área de datos y la regla de nombre como entradas de control. Las pruebas podrían grabar tráfico representativo para rutas normales y excepcionales y comparar salidas en cada frontera.

La enseñanza no es conservar todo artefacto antiguo. Es comprender antes de borrar. Con la ruta visible, el equipo puede sustituir el archivo y la aprobación por un cliente TypeScript y una API. Es un cambio de arquitectura con una obligación de comportamiento conocida, no una eliminación accidental.

Transliterar el grafo conserva fronteras equivocadas

Generar un módulo nuevo por cada programa viejo parece seguro porque la correspondencia se audita con facilidad. También conserva décadas de accidentes de despliegue. El grafo debe preservar obligaciones y revelar fronteras mejores, no imponer una traducción archivo por archivo.

Los límites antiguos suelen venir de restricciones de memoria, ventanas batch, lenguajes o historia de equipos. Un paso JCL puede limitarse a mover datos entre formatos porque ninguno de los programas vecinos admitía ambos. Un procedimiento almacenado puede contener reglas porque el cliente original se desplegaba con dificultad. Un copybook puede acoplar programas sin relación porque era el único medio práctico de distribución. Rehacer cada artefacto en otro lenguaje conserva restricciones que ya no tienen razón.

Use el grafo para hallar comportamiento cohesivo. Los nodos que cambian juntos, comparten reglas transaccionales y participan en el mismo resultado pueden formar un componente moderno. Las aristas que cruzan zonas de confianza, ciclos de entrega independientes o cargas realmente distintas pueden ser interfaces explícitas. Las aristas de datos muestran dónde Postgres debe proteger invariantes. Los núcleos numéricos exigentes pueden justificar Rust, la orquestación puede residir en Go y el trabajo del operador en TypeScript. El destino sigue el comportamiento y las restricciones, no las extensiones.

Desaconsejo empezar por una conversión repositorio a repositorio aunque compras y personal la hagan atractiva. Produce avances fáciles de contar, pero aplaza el comportamiento transversal hasta la integración, cuando cambiar límites cuesta más. Construya primero el grafo del sistema, elija las fronteras nuevas y después reparta los paquetes entre equipos.

La trazabilidad sigue siendo necesaria. Cada componente nuevo debe apuntar a los comportamientos y aristas que reemplaza. Ese mapa permite preguntar si una arista antigua se conservó, se rediseñó deliberadamente o se retiró con pruebas. Sin él, modernizar se convierte en discutir cuánto se parece el código, que es la medida equivocada.

Las pruebas de paridad deben seguir rutas

Las pruebas de repositorio aportan pruebas, pero rara vez demuestran la paridad del sistema porque sus afirmaciones terminan en límites locales. Un banco de paridad debe reproducir transacciones completas y comparar efectos observables a lo largo de la ruta descubierta.

Elija rutas de comportamiento distinto, no solo puntos de entrada frecuentes. Incluya procesamiento normal, destino dinámico, traspaso batch, excepción mediada por operador y fallo o reintento cuando existan. Registre entradas y salidas en fronteras estables: peticiones, cambios de base, registros emitidos, estados, informes y errores visibles. La secuencia interna puede cambiar con la arquitectura. Las obligaciones observables no deben cambiar por accidente.

Un manifiesto compacto hace revisable el alcance:

path: close-exception-approval
entry: account-status-change
observations:
  - eligible-account-row
  - exception-record
  - approval-state
  - ledger-entry
dynamic-targets:
  - reconciliation-program
external-frontier:
  - scheduler-calendar

Para cada caso grabado, ejecute original y reemplazo con estado controlado, normalice valores que pueden variar legítimamente y compare las observaciones. Una marca temporal distinta puede aceptarse; un registro de excepción ausente no. Ante una diferencia, siga la ruta hasta la primera frontera divergente en vez de comparar millones de líneas o solo el estado final.

Las muestras de tráfico requieren complementos deliberados. Reflejan lo ocurrido durante la captura, así que añada casos de límites de calendario, permisos, recuperación, valores raros y acciones de operador halladas por análisis estático. Si este encuentra una rama aparentemente alcanzable sin muestra, no la descarte. Averigüe si está inactiva, es inaccesible o solo rara.

CodeHero lee toda la base de código y sus lenguajes, y verifica el sistema reescrito con un banco de paridad frente a tráfico de producción grabado, entregando el proyecto en menos de 30 días. El criterio útil es el mismo para cualquier método: cada frontera reemplazada necesita pruebas del grafo y del comportamiento a través de ella.

El grafo es un artefacto técnico revisable

Un grafo global merece confianza cuando los ingenieros pueden inspeccionar sus pruebas, reproducir la extracción y registrar decisiones sobre aristas inciertas. Un diagrama bonito sin procedencia es una presentación, no un artefacto técnico.

Mantenga el inventario bruto de aristas bajo control de versiones con identificadores estables para artefactos y ubicaciones. Registre la versión del extractor y la revisión de entrada. Si una arista procede de inferencia, guarde valores y reglas. Si el tráfico la confirma, adjunte un identificador de muestra en vez de datos sensibles. Así los cambios se explican mientras evolucionan el árbol y el diseño.

La revisión debe centrarse en fronteras e incertidumbre. Pregunte qué resultados visibles cruzan repositorios, qué destinos dinámicos siguen abiertos, qué datos controlan el comportamiento posterior y qué sistemas externos introducen trabajo. Un diagrama central gigante es una mala superficie de revisión. Filtre el mismo grafo para una transacción, una frontera abierta, una vista de influencia entre escritura y lectura o el mapa de componentes propuesto.

Asigne propiedad después del descubrimiento. Entregue las aristas abiertas a quienes puedan conseguir exportaciones del planificador, definiciones de base, configuración o procedimientos de operador. Registre la respuesta en el grafo, no en notas. Si declara muerto un artefacto, conserve las pruebas, como valores inaccesibles y ausencia de tráfico suficientemente representativo. El silencio no prueba la retirada.

El primer resultado útil no es un número de archivos ni un total llamativo de nodos. Es un conjunto pequeño de rutas completas con cada transición respaldada y cada incógnita expuesta. Esas rutas permiten a arquitectos dibujar límites, a probadores elegir casos y a operadores reconocer pasos ausentes. Amplíe el conjunto hasta cubrir así los comportamientos del alcance.

Las reglas de compilación eligen la arista real

Los nombres fuente no indican qué implementación se ejecuta. Scripts, mapas de enlace, órdenes de búsqueda, manifiestos, descriptores de despliegue y anulaciones por entorno deciden qué candidato recibe el control. Si el grafo ignora estos artefactos, puede unir el nombre correcto al código equivocado.

Los nombres duplicados son normales. Una versión de prueba puede convivir con producción. Dos bibliotecas pueden contener programas con el mismo miembro. Un proyecto VB6 puede referenciar una interfaz COM compatible mientras el despliegue selecciona una implementación registrada. Sinónimos de base de datos pueden dirigir el mismo SQL a distintos esquemas. El grafo necesita contexto de despliegue, no una respuesta universal que finja que todos se ejecutan.

Modele la resolución como una secuencia de pruebas. Reúna el nombre y la convención de llamada, aplique el orden de búsqueda del entorno, compruebe el punto de entrada y su forma compatible, y adjunte el registro que hizo la selección. Si falta una entrada, conserve candidatos y muestre la decisión ausente en vez de escoger el primer archivo indexado.

Las salidas del enlazador y compilador resuelven preguntas que el análisis fuente no puede. Un mapa de enlace muestra el símbolo incorporado al binario. Los registros indican las versiones de fuentes generadas y copybooks. Los inventarios conectan un artefacto con el host donde el tráfico lo alcanzó. No son papeleo secundario, sino pruebas del sistema ejecutable, y merecen nodos o adjuntos estables.

Mantenga visibles las diferencias entre desarrollo, pruebas, recuperación y producción. El mismo nombre lógico puede resolverse de forma distinta. Fusionar las variantes oculta dependencias exclusivas de producción o hace creer que una prueba ejecutó código que nunca cargó. Etiquete las aristas con su contexto y compárelas. Una diferencia puede ser intencional, pero pertenece al alcance si el reemplazo debe soportar ese entorno.

Este trabajo también encuentra declaraciones obsoletas. Un archivo de compilación puede nombrar una biblioteca ya no distribuida, mientras el binario resuelve todo en otro lugar. A la inversa, un fuente puede parecer sin uso aunque un operador lo compile mediante otro procedimiento antes de una ejecución anual. No elija la historia que prefiera. Registre las pruebas contradictorias y consiga el procedimiento que falta.

La prueba de una arista es sencilla: otro ingeniero debe seguir sus pruebas y llegar a los mismos candidatos bajo los mismos supuestos. La reproducibilidad importa más que forzar una respuesta. Dos destinos defendibles y un archivo de configuración ausente son mejores que una flecha nítida basada en proximidad de directorios.

La identidad de versión también importa después del primer grafo. Una dependencia ligada a una ruta puede desviarse si cambia una rama de entrega, una biblioteca copiada o un miembro generado sin cambiar la ruta. Guarde un resumen del contenido o una identidad de compilación junto al nodo y conecte el ejecutable desplegado con esa revisión exacta. De otro modo, un revisor puede seguir pruebas válidas hasta la versión equivocada y aprobar el reemplazo de un comportamiento que nunca se ejecutó. Esto pesa más cuando los equipos entregan archivos reunidos desde varias máquinas en vez de un checkout limpio. El análisis debe informar rutas duplicadas, marcas de tiempo incoherentes y artefactos sin vínculo demostrable con el fuente. Las alertas no bloquean el descubrimiento, pero evitan una precisión injustificada. Si una exportación posterior aporta el binario o registro que faltaba, la identidad estable permite actualizar las aristas afectadas.

El análisis por repositorio sigue ayudando a entender código local. No puede establecer el límite de comportamiento de un sistema ensamblado con lenguajes, trabajos, almacenes, artefactos generados y acciones humanas. Si las llamadas importantes cruzan los contenedores del análisis, esos contenedores ya decidieron qué omitirá el grafo.