08 enero 2011

Reingeniería de software (1era parte)

Diseñar un sistema desde cero es una actividad creativa y entretenida. Elegimos la tecnología más adecuada, pensamos un diseño que cumpla con las necesidades e intentamos hacer las cosas lo mejor posible.

Luego: nuevos requisitos, tiempos ajustados, parches en el diseño, nuevos desarrolladores, más funcionalidad,  interacción con otros sistemas y tecnologías; más parches, ese framework que era novedoso ya es obsoleto y problemático; cambios de presupuesto, rotación del equipo...

Y así, nuestro hermoso “bebe” devino en una bestia inmanejable.
Hombre lobo o bola de lodo, no importa, cambiamos de trabajo/proyecto y ahora empezamos de nuevo.
Ilusos -todo vuelve- ahora cae a nuestras manos una bestia.

Primer impulso: dinamitemos la cosa y empecemos de cero.
No es mala idea, hay quienes estiman que el costo de mantenimiento va del 50% al 75% del costo total de un sistema de software (Davis, Sommervielle).
El problema es que el costo de desarrollo no es la única variable a tener en cuenta: desde el punto de vista de los negocios comenzar de nuevo puede ser una maniobra de mucho riesgo.

¿Por donde empezar?
Bienvenidos a la reingeniería de software.
Para adentrarnos en este tema vamos a comenzar por ponerle nombre a algunas cosas que probablemente ya sabemos -una tarea muy aburrida pero útil a la hora de buscar y compartir información.

La mayoría de los investigadores en este área utilizan los términos descriptos en el articulo de Chikofsky y Cross y en el paper de Kazman, Woods y Carriere:


Reengineering. Reengineering, also know as both renovation and reclamation, is the examination and alteration of a subject system to reconstitute it in a new form and subsequent implementation of the new form.
Reengineering generaly includes some form of reverse engineering (to archive a more abstract description) followed by some form of forward engineering or re-structuring.

Es decir reingeniería es alterar un sistema existente y cambiarlo de forma para permitir su evolución. Esta tarea incluye entender lo que ya existe mediante ingeniería reversa:

Reverse engineering. Is the process of analyzing a subject system to
identify the system’s components and their interrelationships and
create representations of the system in another form or at higher level of abstraction.

La ingerniería reversa solo abarca la parte de examinar un sistema existente. Esta se puede dividir en dos sub-areas:

Redocumentation. Redocumentation is the creation or revision of a semantically equivalent representation within the same abstraction level.

Design Recovery. is a subset of reverse engineering in which domain knowledge, external information, and deduction or fuzzy reasoning are added to the observations of the subject system to identify meaningful higher level abstractions beyond those obtained directly by examining the system itself.

En ejemplos: Redocumentation es lo que hacen herramientas como Enterprise Architect que generan diagramas UML de clase a partir del código existente. El problema con este tipo de herramientas es que están al mismo nivel de abstracción que el código actual: recorrer un diagrama de clases de este tipo no es muy diferente a utilizar un “browser” de código en un IDE.

Sin embargo para poder comprender un sistema grande se necesita poder recrear otro tipo de información. Por ejemplo poder identificar módulos (más alla de la división de paquetes en el código)  y relacionarlos con la funcionalidad o poder entender la evolución del sistema y su relación con diferentes refactorings, funcionalidad y defectos.

Design Recovery se refiere a este segundo tipo de herramientas, y es donde se concentra el research en el área de reingeniería.

Para poder llegar a hacer herramientas de Design Recovery, primero es necesario tener herramientas que puedan analizar el código. Este tipo de herramientas se llaman herramientas de Program Analysis y las hay de tres tipos: estático (analizan la estructura del código), dinámico (analizan las interacciones en runtime) e histórico (analizan como el código fue cambiando historicamente). Hay varios desafios en el area de program analysis, para hacer un resumen de ellos:

  • análisis estático: lidiar con diferentes lenguajes de programación o scripting en un mismo sistema.
  • análisis dinámico: lidiar con enormes cantidades de información, un simple “trace” de una aplicación real puede ser enorme.
  • análisis histórico: lidiar con herramientas de SCM y el hecho que los “eventos” en el tiempo no son registrados de una forma uniforme.


Hacer Design Recovery significa buscar crear un modelo mental del sistema que permita comprenderlo, lo cual implica buscar formas de visualizar el software. Esto nos lleva a las herramientas de visualización.

Crear visualizaciones de un software no es fácil, por que hay muchas “dimensiones” e interrelaciones, asi que un área de estudio importante es como crear visualizaciones que permitan entender un sistema grande más facilmente.

En el próximo post voy a hablar un poco sobre herramientas de visualización.

Por ahora que ya saben los términos usados en este área de estudio les dejo algunos links a conferencias relacionadas con reingeniería de software: