Un registro, tres programas.
ORDMAIN, ORDCALC y ORDVALID utilizan ORDREC. Cambiar la estructura compartida exige revisar todos los programas que dependen de ella.
MODERNIZACIÓN
DE APLICACIONESCUADERNO
DE CAMPOLógica de negocioDependenciasDecisiones de destinoVerificación
DE APLICACIONESCUADERNO
DE CAMPOLógica de negocioDependenciasDecisiones de destinoVerificación
Del código heredado al cambio deliberado
La plataforma puede cambiar.
El negocio
debe seguir funcionando.
Cada cambio en una aplicación crítica plantea la misma pregunta: ¿qué más depende de este comportamiento? Trazadera modernAIze ayuda a su equipo a comprender el origen, decidir el destino y examinar el proyecto resultante antes de la migración.
01. La lógica de negocio
Empiece por la regla
de la que depende el negocio.
Una aplicación reescrita puede compilar y, aun así, calcular un importe distinto. Antes de cambiar la implementación, haga explícito el comportamiento esperado. En nuestra demostración de gestión de pedidos, el punto de partida es un descuento porcentual.
Gestión de pedidos: ejemplo en COBOL
Calcular el descuento.
Restarlo del pedido.
- Importe del pedido
- 1,000.00
- Descuento
- 10%
- Importe neto esperado
- 900.00
COMPUTE WS-DISCOUNT-AMOUNT =
ORD-AMOUNT * ORD-DISCOUNT-PCT / 100
COMPUTE ORD-NET-AMOUNT = ORD-AMOUNT - WS-DISCOUNT-AMOUNT.La regla de origen proporciona al equipo un resultado concreto que comprobar en la implementación de destino.
Demostración ficticia: tres programas COBOL y una definición de datos compartida, con un destino preparado en Java y Spring Boot.
02. Las dependencias
Delimite el alcance
antes de reescribir.
El cálculo es sólo una parte de la aplicación. Los programas que lo invocan, la lógica de validación y la estructura de datos compartida determinan qué puede cambiarse conjuntamente. La modernización empieza por hacer visibles esas relaciones.
AmpliarUna llamada puede regresar.
El cálculo y la validación pueden invocarse mutuamente cuando el importe neto es negativo. Ese recorrido de retorno debe formar parte del diseño y de las pruebas.
Ver la condición de retorno en el código COBOL
Comprobar qué significa el contador.
ORDVALID incrementa el contador tras un resultado negativo y vuelve a invocar el cálculo mientras sea inferior a tres. El destino Java cuenta los intentos de cálculo. Es necesario revisar explícitamente esa diferencia de significado.
IF ORD-NET-AMOUNT < 0
ADD 1 TO ORD-RETRY-COUNT
IF ORD-RETRY-COUNT < 3
CALL 'ORDCALC' USING ORD-RECORD
03. Las decisiones de destino
Conserve las responsabilidades.
Elija su nueva estructura.
modernAIze utiliza análisis sintáctico determinista y enriquecimiento mediante IA para construir un modelo semántico revisable. Su equipo decide la estructura de destino y las convenciones de las guías de estilo. En esta demostración, los servicios Java separan orquestación, cálculo y validación alrededor de un registro de pedido tipado.
Responsabilidad de origenDestino Java y Spring BootDecisión que revisar
Orquestar el pedido
ORDMAINOrderProcessingServiceDónde empieza y termina la secuencia, y dónde se registra su resultado.
Calcular el descuento
ORDCALCDiscountCalculationServicePrecisión decimal y redondeo de los importes monetarios.
Validar el resultado
ORDVALIDOrderValidationServiceResultados no válidos, límites de reintento y significado del contador.
Compartir la definición del pedido
ORDRECOrderTipos de campo, valores de estado y propagación de las actualizaciones.
Ver el cálculo en Java
BigDecimal discount = order.amount()
.multiply(order.discountPercentage())
.divide(ONE_HUNDRED, 2, RoundingMode.HALF_UP);
return order.withCalculation(order.amount().subtract(discount));Este destino utiliza BigDecimal y redondea el descuento a dos decimales con HALF_UP. El comportamiento del redondeo es una decisión de diseño que debe contrastarse con el origen.
La configuración delimita el origen. La comprensión expone el modelo. La optimización registra las decisiones de destino. La modernización produce el proyecto que se debe revisar.
Conocer modernAIze04. La verificación
Defina una aceptación
que se pueda comprobar.
El destino debe incluir ficheros legibles y comprobaciones concretas. El proyecto Spring Boot preparado compila y supera sus dos pruebas. Son un punto de partida útil para un plan de aceptación más amplio.
17ficheros del proyecto
2 / 2pruebas superadas
Ejecución de la aplicaciónNo realizada en esta demostración
Prueba de cálculo
1000,00 con un 10 % de descuento da 900,00.
El servicio de descuentos del destino devuelve el importe neto esperado para el pedido del ejemplo.
Prueba de procesamiento
Calcular, validar y registrar el resultado.
El pedido se devuelve con un estado válido, un intento de cálculo y una entrada en el repositorio de auditoría en memoria.
Examinar el proyecto de destino
AmpliarVer los resultados de verificación registrados
AmpliarAcordar los casos difíciles antes del cambio definitivo.
Amplíe las comprobaciones a los límites decimales, los descuentos no válidos, los reintentos y las integraciones posteriores. Superar estas dos pruebas no demuestra una equivalencia completa con la aplicación COBOL.
Empezar por una aplicación delimitada
¿Qué comportamiento
debe conservarse tras el cambio?
Aporte una aplicación representativa, sus definiciones de datos compartidas y los casos de negocio que debe seguir resolviendo. Podemos establecer qué se comprende, qué decisiones de destino necesitan revisión y cómo se medirá la aceptación.
Hablemos de una aplicación