Este es un punto donde la calidad de la herramienta con que desarrollamos nuestra aplicación se pone de manifiesto, y nos hace salir adelante, o nos pone en riesgo, o peor, nos deja sumidos en un pantano. Hace mucho tiempo, la flexibilidad para introducir un cambio fue lo que me inclinó por Plex. En algunas herramientas, todo va bien en tanto avanzamos en nuestra definición, pero la diferencia se hace cuando estas deben cambiar. En algunos casos, la respuesta puede ser complicada.
El impacto del cambio se puede ver en dos planos en Plex:
| Una aclaración necesaria: Una parte importante de las herramientas discutidas a continuación, fueron desarrolladas en las versiones más recientes, desde 4.5 en adelante. Es decir, si usted es usuario, pero se mantuvo en un release anterior, aquí encontrará una buena razón para evolucionar |
El propio modelo asegura que un cambio se aplica inmediatamente en toda su extensión. Aquí opera el mecanismo de herencia. Un ejemplo simple es el cambio de un tipo de dato, o de un atributo: una vez producido, todo el modelo lo ve según su nuevo valor. De este modo, si agrego un valor a un campo, o cambio la constante que lo representa, inmediatamente cualquier programa que lo usara lo tiene disponible. Pero, pueden existir conflictos en su uso en la lógica. Así, un nuevo estado en un campo traerá ampliaciones a la lógica, o un campo cambiado en su tamaño puede llevar a errores en su uso (puede existir algún otro tipo de conflicto). Este fue el escenario típico en el problema del año 2000, donde el cambio tenía al menos estos dos aspectos: asegurarse que un dato era uniforme en su definición en todos sus usos, y asegurarse que al cambiarlo la lógica no era afectada. En ese caso, debe hacerse un análisis de "donde se usa", particularmente si se sospecha de que el problema exista (es decir, si cambio un dato de carácter a numérico, por decir algo claro de por sí, debo asegurarme de que al menos no lo usé en un cálculo, porque va a haber un conflicto de tipo de dato)
Existen dos herramientas para analizar el uso de cualquier objeto: el Model Editor, que permite ver los "triples" que describen las relaciones entre objetos del modelo. El Model Editor admite visualizarlo en modo "usage", que nos permite ver dónde un objeto se usa.
Para que especialmente el Model Editor funcione eficientemente, hace falta algún trabajo adicional: adecuar la configuración de análisis de impacto en las opciones generales de Plex.
Debe declararse que muestre los triples de uso (En File/General Options/Impact Analysis), y debe configurarse al generador para que genere los triples de uso ["usage"]
En las versiones iniciales de Obsydian/Plex, no todos los objetos eran visibles en el editor de modelo al buscar su uso, pero en las nuevas versiones se han ido incorporando triples que identifican a casi cada objeto.
La otra herramienta es el Dependency Browser, nacida en la versión 5.0. Trabaja apareado con el Object Browser, y permite arrastrar un objeto desde éste al visor de dependencias, y ver así los dos tipos de dependencias:
De esta forma, es posible en forma rápida detectar todos los usos existentes para cualquier objeto, y arrastrarlos inmediatamente al generador para que regenere y recompile el código ejecutable.
Aquí hay dos tipos de auxiliares: los "preventivos", y los usados durante la generación misma. El gran auxiliar preventivo es la Lista. Los auxiliares durante la generación son: La Lista, usada como resultante, el "call Graph", y los ya mencionados visor de modelo en usage y visor de dependencias
El objeto Lista: A partir de la versión 5.0. Usado en su forma más simple, permite agrupar para documentar y dar sentido a colecciones de objetos, como se haría con una Subject Area, con la que comparte algunas propiedades.Una lista puede incluír cualquier objeto.
Pero la lista es fundamental para el seguimiento de los cambios, si se la habilita en conjunto con la nueva entrada de Model Options. Esta entrada permite configurar una lista para el seguimiento de los cambios en el modelo. Habilitar esta entrada permite que cada cambio efectuado a un objeto se agregue automáticamente a la lista, indicando además su estado respecto a la implementación del objeto (Modificado, Generado, Fallado Generación, Compilado, Fallado Compilación). La lista debiera ser un auxiliar temporal, necesario de eliminar todos los días, a riesgo de perder la pista de los cambios, dada la gran cantidad de información que aporta.
El uso de una lista se inicia en Files/General Options, accediendo al tab de Análisis de Impacto. Aquí se deben habilitar las tres primeras opciones de mantenimiento de listas: Log automático, Estado inicial modificado, y Actualizar estado cuando se genere y compile. Adicionalmente, es conveniente indicar que la lista se elimine cuando llegue su fecha de expiración. Importante: la lista sólo se elimina una vez que deja de ser la lista por defecto de control de cambios. Es decir, primero crea otra que es la lista en uso, y luego, en la siguiente entrada, la anterior será eliminada, o puede ser eliminada manualmente.
El siguiente paso, sigue en Files/Model Options, creando una nueva lista. Se el asigna una fecha de expiración (no obligatorio, pero conveniente, para mantener agilidad en el manejo de los cambios), y se decide qué tipo de seguimiento se habilita. A partir de este momento, cada cambio que se efectúa, queda registrado en la lista, agregándose una entrada, y asignándole una bandera de estado, que luego puede usarse en la ventana de generación para filtrar.
Esta es la lista luego de crear los nombres de implementación de una entidad. Nótese que se agrega un ícono a los objetos modificados (nombres y las tablas a las que se asignó cada nombre), que, en este caso, indica que se ha creado un nuevo cambio. Lo importante es que, una vez que la lista se ha configurado, estas modificaciones son agregadas automáticamente a la lista, por lo que es muy difícil que se pierda el rastro de una.
Al arrastrar la lista a la ventana de generación, tenemos la certeza de que estamos llevando a generar y compilar sólo los objetos que han cambiado desde el momento en que iniciamos la lista. Nótese que el botón de objetos modificados (el martillo) está activado.
La ventana de generación dispone de nueve botones para filtrar los objetos de la lista por estado. Ver todo, modificados, generados, fallados en generación, compilado, fallado compilación, en testeo, testeo fallado, completado.
El visualizador de Dependencias (Dependency Browser): Podemos tomar un objeto, o un grupo, desde el Object Browser, y examinar su lista de objetos heredados, y funciones que lo llaman si corresponde. Basta seleccionar en bloque la lista, y arrastrarla a la ventana de Generación, para que estén en condiciones de generarse los objetos que sean implementables.
El visor de Modelo (Model Editor): Puesto en modo Usage, permite visualizar un objeto implementable "donde se usa", y así enviarlo a la ventana de generación. Los mismos objetos del visor de dependencias, vistos con el editor de modelo, puesto en modo usage.>
