Traducido con permiso por
Dr. Vicent-Ramon Palasí Lallana.
Gerente General de Aurum Solutions.
http://www.aurumsol.com
Julio 2003

Muchas organizaciones informáticas que quieren conseguir ser competentes en tecnologías J2EE (“Java 2 Enterprise Edition” o Edición empresarial de Java 2) desafortunadamente no son realistas sobre la cantidad de tiempo que tarda conseguir esta competencia a desarrolladores de software “de legado”.

• A pesar de la experiencia de estos desarrolladores en lenguajes de programación procedimentales, como COBOL, C o FORTRAN, muchos de ellos pasaron por alto la oleada de tecnología de objetos que tuvo lugar en los primeros años noventa. Por lo tanto, muchos de ellos están comenzando desde el principio – es decir, intentando conseguir competencia básica con los conceptos de objetos para aprovechar el poder de un lenguaje de programación orientada a objetos como, por ejemplo, Java.

  El método para diseñar software anterior a la orientación a objetos se llamaba “descomposición funcional”. Con la descomposición funcional, se comenzaba con una descripción de la función general que una aplicación debía ejecutar – por ejemplo, “proceso de la planilla” – y, entonces, se procedía a descomponer este requerimiento funcional en subfunciones – por ejemplo, “entrada de tarjetas de asistencia”, “cálculo de cheques de pago”, “impresión de cheques de pago”. Esta descomposición (descendente) en unidades cada vez más pequeñas de funcionalidad continuaba hasta que se llegaba al punto en el que todas las unidades eran triviales de programar; entonces, se programaban primero las unidades funcionales más pequeñas, probándolas e integrándolas progresivamente en forma ascendente para construir una aplicación informática.

  Con la descomposición funcional, los datos se consideraban en forma tardía. Por el contrario, en el paradigma orientado a objetos, comenzamos concentrándonos en los datos que se necesitarán para servir como “columna vertebral” de nuestra aplicación: datos en forma de clases y objetos. Las funciones se consideran como un segundo paso en el proceso de modelado de objetos: sólo después de haber determinado la estructura de los datos de nuestras clases y objetos nos concentramos en los comportamientos que necesitamos ejecutar para colaborar en llevar a cabo el “objetivo” de la aplicación en su totalidad.

  Como puede atestiguar cualquiera que haya hecho la transición de la descomposición funcional a la programación orientada a objetos, cambiar de un enfoque centrado en las funciones a uno centrado en los datos cuando se diseña una aplicación parece, al principio, una inversión de conceptos y un paso atrás. Hacerlo representa un cambio importante de paradigma: o sea, un cambio fundamental en la forma en la que percibimos un problema de ingeniería del software, y de ahí que no sea algo que pueda dominarse rápidamente. De hecho, no es raro que los programadores necesiten un año o más de práctica antes de que “lo capten” y eso sólo si tienen disponible un experimentado ingeniero de software orientado a objetos que los guíe.