These tools are capable of selecting the source code of a solution and search for all the dependencies in the code. The tools produces an XML graph with the dependences and Visual Studio is able to draw them (a la Graphviz) and do drilldown from assemblies to namespaces, classes & methods.Hace pocos días se mencionó aquí otro caso, sumamente interesante, por su capacidad de extensión, Modisco. Este conjunto de herramientas está aún en desarrollo, pero apunta en la dirección de mayor interés, que es no sólo descubrir la arquitectura y la lógica de una aplicación antigua y probablemente no documentada, sino también desplegarla en un contexto nuevo, preparada para ser repensada sobre nuevas bases, las que aquí se proponen siempre. Un salto que implica salir de un conjunto de difícil mantenimiento, de conocimiento incierto, a un modelo capaz de ser mantenido, evolucionado, transportado y articulado entre distintas plataformas.
I had to do this manually once: looking for cross references in more than 2.500 mini-applications of legacy code and finished it finally doing some kind of regex searching for the references, creating a text based graph and display it all with the quoted library GraphViz and some clustering techniques.
El problema de la ingeniería reversa de aplicaciones antiguas es complejo, y merece que le dediquemos en algún momento tiempo aparte. Y dadas las complejas posibilidades del entramado de software que cualquier organización encara hoy, atender a sus características y pensar el escenario debiera tener tiempo reservado.
Pero esta nota es para recordar, a propósito de MoDisco, que Plex dispone de una herramienta para facilitar el paso de aplicaciones antiguas a Plex, el Application Generator. Esto es de interés especialmente para quienes lo usan, que no siempre conocen este agregado, para quienes estudian pasar de 2E a Plex, o para quienes buscan una vía de modernización.
¿Cuál es el alcance de esta herramienta? Vale como un auxiliar, básicamente para el reconocimiento del esquema de la base de datos subyacente, y parcialmente para la importación de programas a un modelo Plex. Sólo es aplicable en tres escenarios: un conjunto de tablas posibles de tratar con ODBC, una base de datos DB2 en ISeries, o un subconjunto de este caso, que es un modelo 2E. En el caso de ODBC se pueden importar las definiciones y relaciones entre tablas, y en los otros dos casos se agregan a esta recuperación mínima, la obtención de los programas que manipulan estas tablas. La importación en este caso será como objetos de tipo API, cuyo comportamiento interno se desconoce, pero se exponen al modelo los parámetros que mantiene cada función. La importación no es directa, sino a un estadio intermedio (un repositorio) que es posible modificar, y al que se le puede aplicar herencia, a nivel de cada objeto identificado. La herencia se hace a partir de objetos del modelo al que se importará, con lo que es posible adaptar los objetos antiguos al modelo nuevo.
¿Es esto suficiente? No, evidentemente: un programa importado, al ser una "caja negra", es en realidad un objeto transitorio, que debería reinterpretarse en el nuevo modelo, o permanecer invariable. Este esquema es útil para quien evolucione el antiguo modelo, pasando por una transición manejada.
¿Es posible mejorarlo? Aquí entran las ideas de MoDisco, que parte de una base que es extensible, lo que pudiera abrir posibilides de elaborar herramientas aplicables a modelos Plex. Dado el creciente interés de la comunidad de usuarios de Plex por Eclipse, quizá esto no sea imposible.
¿Qué mejoras esperaría? Ahí caemos a las necesidades usuales en un proceso de ingeniería reversa de un viejo sistema. Y como esto es más general, como se ha dicho, vale la pena verlo aparte, en otro momento. Así será.
No hay comentarios.:
Publicar un comentario