Recientemente tuve el placer de impartir en la Universidad Politécnica de Valencia una conferencia, organizada por el Instituto Tecnológico de Informática, ante un nutrido grupo de empresarios y profesionales que esperaban un tanto de teoría y un mucho de pragmatismo en el acercamiento a la Tecnología de Objetos desde el punto de vista de la empresa, siempre pendiente de presupuestos, cuitas organizativas e imponderables humanos. Naturalmente que poco puede decirse en el reducido espacio de tres horas, pero el éxito de la reunión, sustanciado en la propia evaluación de los asistentes, me hizo considerar la conveniencia de exponer para un público más amplio algunas de las ideas allí enunciadas. Lamentablemente no puede trasladarse -en breve- a un artículo la importancia de la interacción verbal respecto de los problemas particulares de cada asistente, pero intentaré reflejar, sin ánimo de manualizar la experiencia, algunas ideas esenciales que debieran posicionar al lector en el lado pragmático de la orientación-a-objetos. Se tratará aquí mayormente, pues, de una de las tempranas fases de adopción práctica de la tecnología: el primer proyecto de migración: esto es, el puente de ¿dónde? a ¿dónde? pero con objetos. Pero, claro, esto no es el juego de la oca, así que sólo se expondrán notas, ideas y algún comentario, esperando sirvan para aclarar algunos conceptos y desechar otros tantos.

EXPECTATIVAS REALES

Los objetos, contrariamente a lo que muchos piensan (seguramente influidos por curanderos, vudús y programas electorales), no van a solucionar como por ensalmo todos los problemas de una empresa. Ni tan sólo unos pocos. Tal vez ni siquiera los evidencien, o, por el contrario, en el peor de los casos, es posible que los agraven. Sí van a poner en manos de la empresa, empero, recursos efectivos para el tratamiento de algunos de tales problemas. Pero estas “soluciones” no van a resultar gratis, porque el proceso de migración es costoso en muchos sentidos, así que requiere de la empresa la clara y bien fundada determinación de desplazarse hacia la nueva tecnología. Sin una conciencia adecuada de los riesgos que implica este proceso de transformación, el atribulado gestor puede llegar a encontrarse en el peligroso campo de fuego entre los exigentes hitos de productividad y la mirada de conmiseración, cuando no enojada o mayormente lobotomizada, de los programadores. Y es que los procesos de migración hacia nuevas tecnologías encuentran su mayor resistencia en la inercia del personal.

PLANIFICACIÓN

Una deficiente o muy acelerada planificación del proyecto de migración puede convertirse para la empresa en una “vacuna” contra la nueva tecnología, de tal manera que, merced al previsible estrepitoso fracaso, la empresa no querrá oír hablar en mucho tiempo de objetos ni de nada que contenga el grupo de letras “OO”, sin que en realidad se hayan evaluado los pros y contras de la tecnología ahora odiada. En contrapartida, una adecuada planificación de la migración genera cultura suficiente para la extensión de los resultados a otros ámbitos de la empresa, curiosamente -es un decir- con independencia del resultado efectivo final del proyecto atacado. Esto ya indica que la importancia subjetiva del proyecto no va a resultar determinante para su elección como candidato para ser inseminado con objetos.

CONSULTORÍA EXTERNA

Pocos proyectos de migración han triunfado sin el soporte, aun parcial o sesgado, de consultores externos y/o expertos en distintas áreas de la Tecnología de Objetos. Claro que usualmente los presupuestos mandan, pero es útil notar que teniendo en cuenta los costes generales de adopción de la Tecnología de Objetos, los representados por consultores externos suelen enmarcarse en un margen del 1 al 5%. Los consultores externos aportan, a la vez, objetividad y experiencia en áreas similares de negocio, de forma que la evaluación de necesidades, hitos y estrategias puede llevarse a cabo en base a criterios cuando menos prudentes, y no intuitivos, arbitrarios y basados en comentarios, libros y artículos de ... ¿quién? Es apropiado recordar aquí el dicho “El abogado que se representa a si mismo tiene a un tonto por cliente”.

ELECCIÓN DEL PROYECTO

El proyecto ideal de migración debe ser suficientemente importante para que sus resultados tengan relevancia, pero no tan crítico que un fracaso origine un desastre en la organización. Debe elegirse, con todo, el proyecto y no la herramienta: esto es, no se pretende dilucidar la bondad de un producto, sino más bien establecer la base de futuros desarrollos con una nueva tecnología.

CÉSAR O NADA

Uno de los mayores problemas de las organizaciones es que no adoptan un enfoque granular frente a la adopción de nuevas tecnologías, así que para ellas ha de ser o todo o nada (es lo que se conoce como “Absorción Tecnológica Compulsiva”). Y, claro, esto es tan absurdo como pretender ser cinturón negro de Wado Ryu en un mes. El gestor ha de armarse, pues, de calma y proveerse de resignación y buenas dosis de practicidad (así como de buenas cantidades de ansiolíticos y bebidas energéticas de diseño). Así, por ejemplo, el proyecto de migración no necesita contemplar el ciclo de vida completo del software mediante la Tecnología de Objetos, de forma que es posible usar resultados del Análisis y Diseño Estructurado para generar estructuras susceptibles de adecuada codificación en lenguajes orientados-a-objetos; como es posible, también, realizar el análisis orientado-a-objetos, un diseño tradicional y codificar con un lenguaje híbrido. Más que César, el pragmatismo debe imperar.

RAZONES MIGRATORIAS

Antes de acometer un proceso de migración a la Tecnología de Objetos, deben examinarse las razones por las que se intenta el cambio: hasta los animales disponen de razones ante similares traslados, siquiera biológicas. Si lo que se pretende es simplemente “probar” mi consejo, único y tajante, es “No lo haga”: los resultados no servirán de nada, en ningún sentido.

MALAS RAZONES

Naturalmente uno se fia de lo que considera razones, aun cuando éstas no sean más que “razonajes”. He aquí algunas de las malas razones para migrar:

• Haber leído uno o varios artículos O-a-O.
• Desear interfaces gráficos.
• Pensar que se van a eliminar (o reducir) los problemas de ingeniería y modelado.
• Creer que se reducirá el tamño del equipo de desarrollo.
• Examinar una herramienta software.
• Acortar el tiempo de desarrollo mediante la fácil integración de componentes.
• Reducir el tiempo de Análisis y Diseño.
• Crear componentes reutilizables.

PLAZOS Y RECURSOS

Los plazos de acometida del proyecto de migración deben ser flexibles, pero establecidos en un calendario adecuado en el que se especificarán unos determinados hitos a evaluar. Igualmente la administración de recursos ha de ser flexible para permitir cambios originados por una deficiente comprensión inicial de los requerimientos de la migración. En cualquier caso el margen de flexibilidad no deberá superar el 25% de los plazos y/o recursos asignados. Claro que esto queda un tanto laso, pues ¿cómo planificar tales hitos de disposición? Pues con experiencia y tiento, que para eso existen los bien llamados expertos.

HITOS DE VALIDACIÓN

¿En qué áreas habría que establecer hitos (milestones) o puntos de validación para así poder controlar adecuadamente el proceso de cambio emprendido? He aquí algunas ideas (con objetos o sin ellos):

• Formación.
• Inserción de la Tecnología en la Empresa.
• Tiempo de Desarrollo.
• Reutilización de Componentes.
• Creación y Mantenimiento de Componentes.
• Facilidad de medición de la productividad.
• Actitud del equipo de desarrollo.
• Uso de la documentación.
• Generación de documentación de soporte.

EQUIPO DE DESARROLLO

Si las personas son parte primordial en el desarrollo de cualquier proyecto, imaginen su relevancia en un proceso especialmente delicado cual es el de migración. El peligro es que el jefe de proyecto intente acallar el murmullo malintencionado (cuando no la crítica chabacana) de sus programadores mediante la aplicación de sofisticadas herramientas de software (orientadas-a-objetos, ¿cómo no?). Alan Davis acertadamente afirma que “Una buena herramienta en manos de un mal ingeniero de software produce software de mala calidad con muchísima rapidez”.

INERCIA PERSONAL

La importancia de las personas se nota sobre todo en el lastre que aportan a cualquier situación. Respecto de las migraciones una de las mayores dificultades a superar la constituye la usual resistencia al cambio que esgrime el personal de desarrollo de software. Un buen acercamiento, ciertamente infantil pero sobre todo prudente, es hacer hincapié en que se trata de una evolución natural, no de una revolución que desecha todo lo hasta ahora usado y aprendido: y es que las personas, y los programadores de forma exponencial, tienden a considerar que repetir algo un cierto número de años equivale a validarlo como adecuado, útil y ciertamente incuestionable. Finalmente el gestor del proyecto habrá de recabar en que ningun ingeniero de software vale más de lo que vale su actitud, resultando así que es siempre preferible eliminar del proyecto a personas con una clara predisposición a la queja y a la crítica destructiva (las usualmente llamadas “viejas glorias” o “programadores heredados -legacy programmers-”).

SOBRE EL APRENDIZAJE

No puede fiarse un proyecto de migración al conocimiento infuso e inmedido del equipo de desarrollo, por lo común basado en frases como “yo he leído que ...”, “X dice que ...” ó “¡Esto es trivial!”. El equipo necesita, en cualquier caso (que quiere decir “siempre”), pasar por una fase formal de enseñanza reglada conforme a sus circunstancias personales y a las que responden a su inserción en el ambiente de la empresa. Y es que el proceso de aprendizaje debe establecer una base común tecnológica, a modo de tabula rasa, que soporte el posterior desarrollo. No debe confundirse, empero, “aprendizaje” con “capacitación”: una persona formada en Tecnología de Objetos no tiene por que ser una persona capaz de desarrollar software con esta Tecnología. Una de las tareas del instructor, usualmente externo e idealmente interno, resultará ser, así, la de calibración del equipo e identificación de las personas capacitadas para asumir las tareas que se encomendarán en el proyecto.

FASES DE APRENDIZAJE

Mark Lorenz hace tiempo que estableció un esquema temporal de fases para la adopción de la Tecnología de Objetos. He de decir que yo estimo que Lorenz, que se dedica básicamente a la comercialización de su persona como experto en objetos, no acertó totalmente en la segmentación temporal, pero tuvo cierta gracia en la estratificación semántica. He aquí su exposición:

• Novicio (3-6 meses): Se mixtifica el código con la adición más o menos descontrolada de objetos.
• Aprendiz (3-6 meses): Se empieza a ver el significado de la tecnología y se diseñan bosquejos.
• Navegante (Journey Man) (6-18 meses): Los conceptos se aplican ya con soltura, pero todavía se necesita un apoyo exterior.
• Experto (guru) (estadio final, como en el Zen): Todo son objetos: ¿cómo pudo ser antes de otra manera?

SOBRE LA EXPERIENCIA

Un antiguo dicho reza: “El buen juicio proviene de la experiencia; la experiencia proviene del mal juicio”. La experiencia, en sí, no es ni buena ni mala, como tampoco lo es la angostura: todo depende del contexto en que se aplique. Otra cuestión es que la experiencia por lo común embrutece, en su sentido literal, así que no resultará difícil entener que s e hayan obtenido mejores resultados en Tecnología de Objetos con personal sin experiencia previa en desarrollo corporativo. De cualquier manera hay que sopesar que el uso de personal con suficiente experiencia usualmente significa una reducción de los problemas posteriores de integración del software generado en la migración. La cuestión es si la experiencia es o no “reutilizable”, con lo que volvemos al problema de la actitud personal.

TAMAÑO DEL EQUIPO

La masculina frase “el tamaño no es lo importante” adquiere aquí su auténtico sentido: si en general el tamaño del equipo de desarrollo ha de depender del tamaño del proyecto, cabe afirmar que de 3 a 7 personas es un rango razonable para una primera aproximación a la Tecnología de Objetos. Menos de tres personas no suele suponer una muestra aceptable sobre la que validar los resultados obtenidos, mientras que un equipo de más de siete personas usualmente causa demasiados problemas adicionales de gestión de personal que pudieran oscurecer los resultados de la migracion. Con indepedencia del tamaño el equipo deberá contar, en todo caso, con un jefe de equipo, interno o externo.

LEER ANTES DE ESCRIBIR

Una de las primeras cosas que el jefe de equipo (por jefe del proyecto) ha de plantearse es la de cambiar los hábitos de los programadores (ardua tarea, a fe mía), para que lean y busquen antes de codificar. Y es que, por ejemplo, en C++ se lee al menos el 60% del tiempo para encontrar componentes que reutilizar. Pero también en Smalltalk continuamente se explora el entorno para encontrar soluciones o patrones que puedan aplicarse a los problemas de codificación (hasta el punto que se ha convertido en una costumbre la carencia de documentación respecto de la funcionalidad de los entornos Smalltalk). Naturalmente el problema surge en el control de producción: las líneas de código (NCSLs) no son ya buen parámetro. Pero las métricas orientadas-a-objetos son otra historia, difusa cuando menos.

EL EQUIPO ANTE TODO

“La primera tarea de un nuevo jefe de equipo debe ser la de identificar todo el personal sin el que no puede pasar y despedirlo” es una frase un tanto brutal que expone la coherente animosidad personal como una condicion indispensable para pertenecer, en nuestro caso, al equipo de desarrollo de un proyecto de migración.

ELECCIÓN DE METODOLOGÍAS

Hay que decidir qué parte del ciclo de vida del software va a ser objeto de la migración. Si el segmento elegido es el de Análisis y/o Diseño, habrá que decidir cuál usar de entre todos los métodos disponibles. La cuestión es que para poder escoger con propiedad un método de análisis y/o diseño orientado-a-objetos hay que conocerlos todos (inefable y decepcionante verdad). El método deberá ser elegido, con todo, en función de su idoneidad para el proyecto: objetivos demasiado generalistas pueden tornarse inmanejables por falta de adiestramiento.

MÉTODOS COMERCIALES

El gestor se encontrará, sin apenas pedirlo, con la siguiente clasificación (una supuesta partición) de métodos de OOA/OOD:

• Estáticos (enfocados a datos): lo importante es la estructura de datos anexa a los objetos y a las operaciones que sobre ella se aplican.
• Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un objeto tiene sentido en estos métodos cuando exhibe un comportamiento diferencial respecto del resto de los objetos.

Lo malo es que esta distinción es arbitaria y usualmente no ayudará en la elección de un método u otro.

MÉTODOS DE OOA/OOD

El encargado del proyecto de migración se sentirá en esta fase (la electiva) como Ulises ante el canto de las sirenas, aunque sin atadura alguna y, por tanto, sujeto a seducciones “peligrosas”, mayormente comerciales. He aquí parte de la torre de babel (pozo de babel, que diría Kafka):

• Object Oriented Design (OOD), Grady Booch.
• Object Behaviour Analysis (OBA), Rubin & Goldberg.
• Object Oriented Software Engineering (OOSE), Ivar Jacobson.
• Visual Modeling Technique (VMT), IBM.
• Object Modeling Technique (OMT), Rumbaugh y otros.
• Better Object Notation (BOM), Nerson.
• General Object-Oriented Design (GOOD), Seidewitz & Stark.
• Object Oriented System Analysis (OOSA), Shlaer & Mellor.
• Object Oriented Structured Design (OOSD), Wasserman y otros.
• Systems Engineering OO (SEOO), LBMS.
• Syntropy, Cook y otros.
• Object Oriented Jackson Structured Design (OOJSD), Jackson.
• Hierarchical Object Oriented Design (HOOD), ESA.
• Colbert, E. Colbert.
• Object Oriented Analysis (OOA), Coad & Yourdon.
• Object Oriented Design (OOA), Coad & Yourdon.
• Object Oriented System Analysis (OSA), Embley, Kurtz y Woodfield.
• Frame Object Analysis (FOA), Andleigh & Gretzingr
• Semantic Object Modeling Aproach (SOMA), Ian Graham
• Berard (BOOM), Berard.
• ADM3, Donald Firesmith.
• Object Oriented Role Analysis and Modeling (OORAM), Reenskaug y otros.
• Fusion, Coleman y otros.
• Desfray, Softeam.
• Responsibility Driven Design (RDD), Wirfs-Brock y otros.
• Methodology for Object Oriented Software Engineering of Systems (MOSES), Henderson-Sellers & Edwards.
• Texel, Texel

MÉTODOS MÁS EXTENDIDOS

Una opción muy socorrida (las ataduras de Ulises) es la de buscar quién y cuánto usán qué métodos. Se trata, pues, del abuso de la estadística matizada por la publicidad tendenciosa. Puede sostenerse, empero, que algo ha de haber tras tanta aceptación, así que habrá que detallar los métodos tópicos (como su uso):

• JACOBSON, para Casos de Uso, pues establece escenarios y sirve para validar procesos.
• CRC (Clase-Responsabilidad-Colaboración), para descubrimiento de clases, métodos e interacciones entre entidades.
• OMT, para Análisis, fundamentalmente por su excelente y clara notación de relaciones estáticas.
• BOOCH, para Diseño, por la riqueza de su notación, reflejo de las interacciones entre entidades.

POSIBLES ENFOQUES METÓDICOS

Saber qué métodos son los más utilizados tiene su interés, seguramente, pero las empresas suelen necesitar de enfoques “globales” que, aparte de proporcionar una cierta sensación de seguridad, son más fáciles de explicar al cuadro directivo. Las posibilidades son las siguientes:

• Métodos de 2ª Generación , que sirven de guia formal para la aplicación de uno cualquiera de los métodos anteriores.
• Mixtificación o refrito de Métodos , de desarrollo comercial o interno, buscando utilizar lo mejor de cada método.
• Marco Referencial de Métodos , donde se ponen a disposición del equipo, en un entorno formal, distintos métodos adecuados para cada posible situación.

MÉTODOS DE 2ª GENERACIÓN

Se trata de marcos “formales” (en algún sentido) que proporcionan soporte (en algún otro sentido) a métodos aparentemente más elementales. De entre todos ellos sobresale FUSION, que proporciona un soporte (superficialmente) riguroso en el que incrustar los resultados obtenidos de BOOCH, Jacobson, OMT o CRC. Lo bueno de Fusion es que proporciona una buena integración con el método en cada caso utilizado. Lo malo es que Fusion está siendo muy contestado en el entorno industrial precisamente por su enfoque “global”, que se asimila a “quien mucho abarca poco apreta”.

MIXTIFICACIONES

Ante la perspectiva de la globalización cuestionable surge un enfoque basado en el “Picking”: se trata, así, de una solución ecléctica, que recoge lo supuestamente mejor de cada método. Ni que decir tiene que éste es el planteamiento más popular y extendido, porque se adapta a la naturaleza acomodaticia del ser humano. Suele ser, también, el enfoque más adecuado para un proyecto de migración, pero resulta demasiado débil para basar en él la totalidad del desarrollo de una empresa. Por si no quedó claro, la opción de aglutinar las “afinidades electivas” supone el conocimiento de todos los métodos involucrados.

EL MÉTODO UNIFICADO

La compañía Rational Inc. ha “comprado”, sucesiva e irremediablemente, los métodos BOOCH, OMT y JACOBSON (exactamente a sus autores, se miren como se miren las matizaciones de este verbo, sin ningún ánimo despectivo por demás) y ya ha lanzado la primera especificación de “El Método Unificado”, que sobre un supuesto modelo común de objetos permite bien un desarrollo compatible con cada uno de los métodos, bien una integración de notaciones “buena para todo”. La verdad es que puestos a adoptar una mixtificación, al menos ésta de Rational reúne algunas interesantes características de cohesión e integración conceptual. Sí hay que anunciar, no obstante, que la adopción del Método Unificado no supone la necesaria adscripción a las herramientas CASE y de desarrollo de Rational Inc. o de cualquier otra firma.

MARCOS REFERENCIALES

Es el enfoque más completo, pero también el más difícil de implantar, porque supone la creación en el seno de la empresa de un conjunto de herramientas de análisis, diseño y codificación que puedan ser usadas, en subconjuntos, por los diferentes equipos de desarrollo para atacar problemas concretos. La idea básica es que un sólo método (aun unificado) no puede cubrir de manera efectiva el panorama de problemas a modelar.

MODELOS DE ROLES

Casi todos los métodos están basados en la dicotomía CLASE-OBJETO, a excepción de OORAM, que se basa esencialmente en ROLES: esto es, en el comportamiento posicional de un objeto/entidad respecto de una o más relaciones en una estructura colaborativa o modelo de roles. OORAM es una de las metodologías más completas del panorama actual de OOA/OOD, con más de 20 años de antigüedad, por lo que ignorarla es un delito que traspasa lo económico.

PATRONES DE DISEÑO

Una de las mejores maneras de comunicar a los analistas y diseñadores novicios los exitosos esquemas de otros desarrollos y las estructuraciones que solucionan problemas concretos es mediante el uso de patrones, entendiendo un patrón como “una solución a un problema dado en un contexto preciso”.

CATÁLOGOS DE PATRONES

Existe un elevado número de catálogos con soluciones para distintos problemas de diseño de sistemas:

• Gestión de entornos gráficos (MVC)
• Comandos recuperables (Command: do-undo)
• Iteradores
• Embellecedores (Decorator)
• Factorías de objetos (Factory)
• Etc., etc.

El más importante catálogo es el del libro “Design Patterns” de Gamma y otros, pero también existen servidores web de patrones.

ELECCIÓN DE LENGUAJES

El lenguaje de programación es importante, pero no es lo más importante, pues no es más que un instrumento que aporta facilidades para la construcción de sistemas software. La decisión final deberá tomarse, con todo, en razón del proyecto concreto elegido, pero teniendo en cuenta que un procesador de textos no convierte en buen escritor a un anodino escribiente, de manera que no hay que fiar al instrumento las imposibilidades de su usuario. Una vez valorados estos riesgos, una de las primeras consideraciones que surgen en un típico proyecto de migración es la de si usar o no usar C++.

PROBLEMAS DE C++

Es un lenguaje muy difícil de aprender, pues está repleto de sutilezas de difícil control, sobre todo respecto, de un equipo de programadores. La periodificación de adopción del lenguaje podría ser la que sigue:

• Seis meses para un manejo con elemental seguridad
• Un año y medio para un control adecuado
• Tres años para su uso en proyectos críticos

Hay que notar también que los compiladores y herramientas observan importantes atrasos respecto del estándar, además que los programadores de C deberán ser totalmente (con alguna excepción honrosa) reciclados. Por último cabe notar que C++ está todavía en proceso de estandarización por ISO y ANSI X3J16, de forma que el lenguaje todavía puede cambiar, aun muy débilmente.

VENTAJAS DE C++

C++ es el estándar “de facto” en la industria, y sirve como “ensamblador universal”, pues dispone de compiladores en prácticamente todas las plataformas. C++ es, a la vez, un lenguaje muy efectivo (tanto como C, con el que puede llegar a integrarse grandemente), y además dispone de características (como las plantillas o “templates”) que pueden disminuir drásticamente los plazos de codificación.

FASES DE ADOPCIÓN DE C++

• C++ como mejor C:
  • Sobrecarga de funciones y operadores
  • Fuerte chequeo de tipos
  • Mejoras sintácticas
• C++ basado en objetos
  • Clases
  • Datos y funciones miembros
  • Plantillas (tipos parametrizables)
• C++ orientado a objetos
  • Derivación de clases
  • Funciones virtuales

SMALLTALK

Es un lenguaje esencialmente dinámico, donde todo son objetos, que se comunican mediante mensajes, e incorpora, además, su propio entorno de desarrollo (significativamente el de construcción de interfaces gráficos), de forma que raramente se necesitarán bibliotecas adicionales (que también existen, naturalmente, aunque muy especializadas). Smalltalk es un lenguaje interpretado, de forma que su eficacia es alrededor de 20 veces menor que la de C/C++, pero, claro, esto habría que matizarlo en razón del código a comparar elegido, y contrastándolo con un código C++ efectivamente perfecto.

SMALLTALK CORPORATIVO

Smalltalk provee muchas facilidades para el control del trabajo en equipo, favoreciendo así la reutilización del trabajo y la integración de componentes. El lenguaje permite, además, menos ocasiones para el ejercicio de “la explosión creativa” de los programadores indisciplinados, asegurando por tanto cierto “sabor corporativo”. El código Smalltalk puede examinarse y validarse con relativa rapidez, por lo que resulta relativamente fácil el establecimiento de normas de estilo.

OTROS LENGUAJES

• Eiffel : carente de una adecuada colección de bibliotecas comerciales y de una tecnología de compilación incontestable. Es tan atractivo académicamente como comercialmente desconocido.
• Ada-95 : la normalización orientada-a-objetos de un clásico del DOD. Clásico.
• Java : el último grito: C++ hecho fácil, con seguridad adicional, tipos y protocolos dinámicos, multi-hilo. Aún inmaduro como puro mensaje, fuera de las cuitas de internet.

CONSTRUCCIÓN DE INTERFACES

No hay que confundir los facilidades que aportan ciertos lenguajes para la construcción de interfaces con las facilidades para la programación orientada-a-objetos. Existen lenguajes/entornos no-orientados-a-objetos que proveen herramientas visuales para la construcción de interfaces, como Visual Basic o Borland Delphi, y que usualmente alcanzan su sentido como front-ends visuales de bases de datos relacionales. Por otro lado los lenguajes de programación orientados-a-objetos también proporcionan por lo común herramientas suficientes para los adecuados manejo y construcción de interfaces gráficos.

ELECCIÓN DE HERRAMIENTAS

Una parte esencial del proyecto de migración la constituye la de la elección de herramientas, usualmente en las siguientes áreas:

• Compiladores
• Bibliotecas de clases
• Frameworks
• Herramientas OOCASE
• Bases de objetos

El motto a tener en mente ha de ser siempre “No se debe reinventar continuamente la rueda”.

BIBLIOTECAS DE CLASES

Existe un enorme y variado mercado de bibliotecas de clases (class libraries) para distintos lenguajes de programación, aunque la mayor parte son de C++. Tales bibliotecas permiten el desarrollo rápido y seguro de aplicaciones, proporcionando módulos ya validados y estables que pueden utilizarse tal cual o modificarse diferencialmente mediante el uso de la herencia.

CATÁLOGOS DE CLASES

Existen multitud de bibliotecas de clases dedicadas a casi cuanto uno pueda imaginar (lo que indica que hay que buscar componentes “utilizables” antes de empezar a codificar). He aquí una pequeña muestra:

• Construcción de Interfaces Gráficos.
• Cálculos Científicos.
• Acceso de Tablas Relacionales.
• Manejo de Gráficos.
• Plantillas y Contenedores.
• Comunicaciones
• Multimedia
• Proceso de Textos
• Etc, etc, etc.

FRAMEWORKS

Un framework (entorno-marco) es una conjunción de distintas clases que configura un entorno de trabajo con sus propio estilo de codificación (idioma), arquitectura (patrones) y reglas de extensibilidad (derivación restringida).

¿FRAMEWORKS O BIBLIOTECAS?

Los frameworks se están imponiendo en los entornos corporativos, principalmente debido a que ya incorporan patrones arquitectónicos de fácil control. Las bibliotecas permiten, por otro lado, una mayor flexibilidad integradora y de uso. El límite entre frameworks y bibliotecas es difuso, pues un framework es, al fin, una biblioteca de clases. Podría decirse que los frameworks son a las bibliotecas de clases como los 4GLs a los lenguajes 3G.

HERRAMIENTAS OOCASE

Las herramientas OOCASE son necesarias, pero poco a poco van siendo sustituidas por entornos de programación que abarcan el ciclo de vida completo del software. En cuanto a su elección, bueno, existen unas cuantas: las herramientas OOCASE que intentan tratar muchos métodos no logran tratar ninguno con precisión, mientras que las dedicadas a un solo método impiden la adopción particularizada del “Método de la Mixtificación”. Yo diría que “La mejor herramienta OOCASE es la que no existe”, así que mi consejo respecto de ellas sería: primero intentar prescindir de ellas, y si no se puede, entonces probar con una freeware (como por ejemplo la bien acabada y completa VALISE, de Hitachi), y después con una muy barata, y así en adelante.

BASES DE OBJETOS

Las bases de objetos, divididas en

• Bases de Objetos Puras (OODBMS)
• Gestores de Almacenamiento Persistente (PSM)
• Envoltorios de Objetos (OW)
• Bases de Datos Relacionales Orientadas-a-Objetos (OORDBMS)

en razón de su “puridad”, son adecuadas “según para qué”. Ciertamente son insustituibles en determinados entornos o para resolver adecuadamente algunos problemas, pero su uso en un proyecto de migración debería quedar limitado a la estricta “receta facultativa”.

GESTIÓN DE PROYECTOS

Lamentablemente la gestión práctica de proyectos orientados-a-objetos está aún en mantillas, debido fundamentalmente a que la mayoría de empresas considera sus “historias de éxito” como ventajas competitivas estratégicas. Los consultores externos vuelven a ser una de las pocas soluciones posibles para empresas sin un presupuesto que cubra errores gruesos. Y es que, como establece Alan Davis, “Una buena gestión es más importante que una buena tecnología”.

CICLO DE VIDA

El ciclo de vida de software orientado-a-objetos es una variación del ciclo en espiral de Boehm, conocido como modelo de fuente o modelo de piscina, y que Edward Berard resumió como “Analiza un poco, diseña un poco, codifica un poco, testea un poco”.

INVOLUCIÓN PERMANENTE

No existen fases estancas en OOA/OOD, pues el diseño no espera a tener completos los resultados del análisis, y se empieza a codificar sin tener completos los resultados del diseño, a la vez que se validan los módulos a lo largo de todo el proyecto, trayecto durante el que se producen varias iteraciones que refinan el modelo hasta obtener una aplicación estable.

DISEÑO FLEXIBLE

En vez de tratar de construir un sistema con bloques de metal (el resultado inamovible de las fases tradicionales de análisis y diseño), el sistema en Orientación-a-Objetos se modela primeramente como si de plastilina se tratara, para, en sucesivas iteraciones, darle completa forma. Si se produce, así, algún cambio de especificaciones durante el desarrollo del proyecto, éste se incorporará al tratamiento normal de cambios, de manera que su repercusión habrá de ser mínima.

DIFICULTAD DE GESTIÓN

Al no darse fases estancas, es muy difícil establecer puntos de control o hitos sobre los que basar la gestión del proyecto. Si recabamos, según lo ya expuesto, en que todavía no existen técnicas maduras que permitan la medición y el control de la productividad del software Orientado-a-Objetos, resultará siempre aconsejable que una persona experta supervise los proyectos de migración, ayudando así a establecer futuros hitos de control.

CALIDAD

Las cuitas de calidad del software han de enfrentarse de la misma forma involutiva e iterativa en que se asimila el proceso de análisis-diseño-implementación. Y es que “La calidad respecto de un proyecto software no es como el azúcar al café: no puede añadirse después de terminado”.

CONCLUSIONES RÁPIDAS

El proceso de migración hacia la Tecnología Orientada-a-Objetos, si bien proporciona beneficios tangibles, es largo en el tiempo, costoso y no exento de riesgos. Si se quieren minimizar estos riesgos la empresa se ayudará de consultores externos y expertos, que adecuarán los distintos métodos, técnicas y herramientas al proceso productivo y a los recursos humanos y materiales de la empresa, generando a la vez documentación sobre el proceso, de inestimable valor para la empresa.