A la hora de plantearme una revisión de un producto comercial, cual es éste, me he interrogado sobre qué busco cuando leo una tal en revistas técnicas. Y he encontrado que, más que visiones generales y detalles técnicos, usualmente necesito respuestas rápidas a preguntas concretas: ¿Debo actualizar la versión? ¿Sirve para trabajo en grupo? ¿Pagaré la sofisticación del producto con mi carne y mi tiempo? ¿Quién es Bill Gates? Aquí van, desordenadas, preguntas y respuestas, opiniones ambas al fin:

¿Qué requerimientos físicos tiene VACPP30 para OS/2?

Tras realizar pruebas con distintos equipos y trabajado con proyectos no triviales, yo diría que la configuración mínima razonable [1] es un equipo Pentium con 32 Mb de RAM y 350 Mb de espacio en disco.

¿Qué componentes incorpora?

Las porciones básicas del producto, aparte de las utilidades de gestión de clases del WorkPlace, son:

• VisualAge Compiler and Linker : compilador y enlazador optimizados (respecto de C Set++) y con un aluvión de opciones en línea (sí, lector, el compilador se llama en línea de comandos). La adición más importante es el Soporte Direct-To-SOM [2] (DTS): en vez de generar a mano clases IDL, para instanciar objetos SOM, el compilador hace el trabajo por nosotros, lo que permite usar unas cuantas posibilidades adicionales de C++, como plantillas, miembros estáticos, etc.
• WorkFrame : la plataforma de salida y control de las demás porciones.
• Project Smarts : un generador automático y no configurable de esqueletos de aplicaciones-tipo: DLL C, C++ y de recursos, aplicaciones PM, aplicaciones visuales VB, aplicaciones del WorkPlace Shell, y unas tantas más. El código se genera y luego ... a modificarlo.
• Visual Builder : un constructor de IGUs con características propias.
• C++ Browser : una herramienta para navegar textual y visualmente (listas y gráficos) a través del código compilado o pendiente de compilar (mediante Quickbrowse).
• Data Access Builder : generador de clases para el acceso a tablas DB2/2.
• VisualAge Editor : un editor de código fuente francamente bueno, totalmente configurable y programable: una pequeña joya que incorpora sensitividad respecto del lenguaje (realce mediante colores de palabras reservadas), gestión transparente de errores, opciones multi-vista del código y personalización extrema (mediante la adopción de personalities, como la del EPM)
• PM Debugger : lo mejor del depurador es que opera sobre OS/2.
• Performance Analyzer : este traceador vuelca información del código en ejecución y permite analizar, con diagramas gráficos y textuales, llamadas y retornos de funciones, interacciones multi-thread, etc.
• IBM Open Class Library : una biblioteca muy bien diseñada comprehensiva de cerca de 400 clases C++ y 4.000 funciones miembro: colecciones, interfaces de usuario, soportes de aplicación y clases estándar.
• Dialog, Font and Icon Editors : las mismas pobres herramientas de siempre, aunque con el Constructor Visual pierden sentido ciertos aumentos de funcionalidad. Se necha en falta, empero, herramientas más acabadas como, por ejemplo, las de JBA Guidelines para OS/2, que permiten la evaluación inmediata de lo construido (a costa, claro, de operar con un lenguaje intermedio adicional: otra insufrible cadena)

¿Debo actualizar C Set++ versión 2.X a VACPP30?

Oh, sí, sin duda. Sólo tiene que cumplir los requisitos de hardware. Las mejoras son sustanciales.

¿Debo adquirir VACPP30?

Mi opinión es que VACPP30 es el mejor conjunto actual de herramientas de programación C++ para OS/2. Lo que es mucho o nada, teniendo en cuenta la desafortunadamente escasa implantación de este sistema operativo.

¿Es la instalación sencilla y práctica?

Atendiendo a los problemas usualmente adscritos a los sofisticados productos actuales, la pregunta no es trivial. La respuesta es parcialmente satisfactoria: IBM utiliza su propio programa instalador, común a una amplia gama de sus productos, que ofrece la instalación, actualización y borrado de distintas partes del producto y que funciona prudentemente bien, pero se echa en falta el soporte para instalar únicamente lo mínimo en el disco duro y trabajar desde el CD, pues hay que tener en cuenta que el producto completo, con ejemplos y documentación electrónica, ocupa unos 210 Mb.

¿Qué tal con el desarrollo multiplataforma?

Capacidad multi-plataforma significa, en el contexto usual de herramientas de desarrollo en C++, que el código compilará con escasas modificaciones en las plataformas para las que existe el mismo producto (en el caso actual: OS/2, AS/400, AIX, MVS y Solaris). En realidad la portabilidad de la IBM Open Class Library tiene mucho que ver con esto, pues como veremos las distintas partes del producto la usan intensivamente. Y en cuanto a Windows 95 y NT, bueno, habría que confiar en la constancia de IBM [3]. Aparte de pruebas benéficas, yo confiaría únicamente en lo disponible en cada momento.

¿Es bueno el compilador C++?

A mi entender IBM posee uno de los mejores compiladores C++ del mercado, ajustado al borrador del estándar C++, aunque con particulares decisiones de implementacion de ciertas características del lenguaje. Pero, claro, quien haya leído el borrador del estándar enseguida comprenderá la necesidad de tomar decisiones prácticas. VisualAge C++ está basado en el estandar C ANSI/ISO 9899-1990[1992] y en el borrador del estándar C++ ANSI X3J16/92-0060, (17-09-1992) [4], según la interpretación de IBM de este último realizada en marzo de 1993. El código resultante es, por otro lado, de los más rápidos que he analizado.

¿Proporciona soporte para el trabajo en equipo?

No. Y el hecho que la mayoría de compiladores de PC tampoco otorguen tal soporte no quita metal a la carencia. Y si el lector se siente tentado a pensar en redes deberé señalarle que “trabajo en grupo” supone bastante más que un mero control de acceso a recursos: versiones, ediciones, integración, control, etc. configuran un esquema de producción que en absoluto se da aquí [5]. Sólo se dan opciones de configuración local que se calificarían más bien de “trabajo de segmentación en grupo”.

¿Cómo es la integración de los componentes de desarrollo?

Muy buena. VisualAge C++ utiliza intensivamente las posibilidades de OS/2, así que el WorkFrame funciona a modo de un escritorio particularizado y aislado del resto (no funciona en él, por ejemplo, el drag-n-drop a la trituradora del sistema), desde el que se lanzan, integran y controlan las distintas herramientas del producto: Compilador, Enlazador, Depurador, Constructor Visual, Editor de Diálogos, Traceador, etc.; independientemente, por supuesto, del uso separado que en cualquier momento puede hacerse de cada una de ellas: yo, por ejemplo, suelo usar el excelente Editor de Código programable para casi todo, incluido el acceso al sistema operativo. La ventana del WorkFrame contiene los ficheros del proyecto, además de un visor opcional con los resultados de la invocación de las distintas utilidades. El mayor defecto de los componentes de VisualAge C++ es su escasa rapidez operativa: en un 486/DX66 con 24 Mb de RAM puede verse como se dibujan las ventanas de cada utilidad; y su rendimiento es inesperadamente corto, con independencia de la gran calidad del código que generan.

¿Y el soporte para acceso a bases de datos?

VisualAge C++ incorpora un componente denominado “Data Access Builder” (Constructor de Acceso a Datos) que automatiza la creación de clases a partir de tablas DB2/2 y en base a un subconjunto de la IBM Open Class Library. El usuario escoge una o más tablas y la herramienta encapsula, automáticamente o mediante correspondencia manual columnas-atributos, las llamadas de lectura y escritura a cada una de las columnas de la tabla en métodos de lectura y escritura de una clase, dando la opción de generar código IDL o C++, que más tarde podrá ser también utilizado como parte visual en el Constructor Visual. Más tarde esta generación podrá visionarse mediante una tosca graficidad. Desafortunadamente DB2/2 es la única base de datos soportada en esta versión, que también provee servicios separados para la conexión y desconexión, así como operaciones “commit” y “rollback”.

¿Es realmente utilizable la biblioteca de clases?

La Open Class Library es una magna biblioteca de clases C++ compuesta por varios subconjuntos perfectamente diferenciados:

• I/O Stream Library : manejo de “streams” de entrada/salida, según la implementación 3.0 de UNIX System Laboratories.
• Complex Mathematics Library : manipulación de complejos y operaciones matemáticas.
• Data Access Builder Class Library : el soporte del generador automático de clases para tablas DB2/2.
• User Interface Class Library : un auténtico marco-aplicativo para el desarrollo de porciones visuales, proveniente del C Set++ y grandemente basado en los widgets de Motif, con conexiones de bajo nivel al API, y por tanto al look-n-feel, correspondiente a cada plataforma.
• Collection Class Library : contenedores en el más puro estilo Smalltalk. La biblioteca de clases de interfaz de usuario los usa intensivamente.
• Data Type and Exception Classes : clases “String”, “Date” y jerarquía de clases para el tratamiento de excepciones (IaccessError, IOutOfMemory, IInvalidParameter, etc.), originariamente incorporadas en la biblioteca de clases de Interfaz de Usuario.

Todas estas porciones configuran un soporte de clases de indefectible estudio para todos aquellos que confíen sus posibilidades multiplataforma a IBM.

¿La documentación es suficiente y adecuada?

¡Ciertamente! Sólo hay que reparar en el enorme tamaño de la caja opcional de documentación. De cualquier forma los manuales vienen con el producto en formato INF.

¿Qué le falta?

Quizás la biblioteca estándar de plantillas, STL. Hay que tener en cuenta que el sistema hace uso intensivo de los contenedores tipo Smalltalk que contiene la IBM Open Class Library, tanto para el cálculo algorítmico como, y esto es esencial, para la construcción de partes visuales, por lo que la STL queda un tanto desdibujada internamente. La ausencia es, con todo, inexplicable [6], forzando al usuario a adecuar el código freeware o a comprar una implementación comercial ajustada al compilador (como, por ejemplo, STL<ToolKit> de ObjectSpace Inc).

¿Y la construcción de interfaces gráficos?

Es costumbre que los compiladores de C++ para PC acompañen, como parte indispensable del lote comercial que comprenden, utilidades de construcción de GUIs basadas en las bibliotecas de clases que cada compilador provee. Naturalmente es lo que más suele llamar la atención del usuario; lamentablemente, también, las calidades de biblioteca y constructor visual suelen ser independientes. En el presente caso, el constructor visual de VisualAge C++, denominado “Visual Builder”, está basado en los componentes visuales y contenedores de la biblioteca de clases “IBM Open Class Library” que acompaña al producto, así que “miel sobre hojuelas”.

El interfaz del Visual Builder es un calco del de VisualAge Smalltalk [7] a excepción, claro está, de la opción de ejecución, que en C++ se transforma en la de generación de código. Las diferencias internas son más profundas, pese a que la intención es singularmente parecida: la facilidad de prototipación de Smalltalk se pierde en la versión C++, y el código que genera ésta no mantiene ninguna relación con la parte visual, excepto la unidireccional de generación. De esta manera, cuando se genera código para una parte visual y más tarde se cambia la parte y vuélvese a generar código, se sobreescriben los ficheros. Estos problemas de generación automática de código son comunes a la mayoría de kits visuales en C++ (con la excepción de aquellas bibliotecas que crean discutibles ficheros de recursos multi-plataforma, interpretables en tiempo de ejecución), y suelen obviarse derivando de las clases generadas unas nuevas clases en las que se aplican las modificaciones, que así no serán machacadas en sucesivas modificaciones de las partes visuales.

Para cada parte (por clase) construida con el Visual Builder, éste genera un fichero con extensión “VBB”, que contiene la clase en formato inteligible para el constructor, además de un fichero “HPP” con la declaración de la clase, otro “CPP” con las definiciones, un “H” como archivo de recursos y un “RCI” con el texto de los recursos externalizados. Si la parte que se edita con el constructor visual es el punto de partida de la aplicación, además habrán de generarse, seleccionando la opción correspondiente del menú, los ficheros “APP” y “RC”, además del “MAK” si se desea.

La principal ventaja del Visual Builder sobre otras utilidades análogas (lisez Wizards de Microsoft, Experts de Borland, etc.) es que se trata de una capa que permite la construcción tanto de partes (clases) visuales como no-visuales, tratando ambas de forma mayormente visual. A tal fin, e intentando que el programador no abandone el entorno del constructor para codificar “a mano” métodos casi siempre necesarios en aplicaciones no triviales, se han provisto browsers visuales muy al estilo Smalltalk que, en consecuencia, generan clases que adolecen de una cierta esclavitud y enfermedad derivativa. Visual Builder llega, con todo, donde otros constructores visuales no alcanzan, constituyéndose en marco desde el que abordar aplicaciones completas [8].

¿Mis consideraciones finales?

Aunque a más de uno le pueda sorprender tener que invocar el compilador C++ desde la línea de comandos a la vez que se trabaja al lado en un muy sofisticado componente visual, quizás para mí ésta sea una de las características más importantes del producto: su granularidad de uso. El programador puede elegir el nivel de uso de los distintos componentes, de forma que la configuración resultante sería, en cualquier caso, la más adecuada a las posibilidades del usuario.

En cuanto a su adopción masiva, desde luego es una opción ineludible en desarrollo de aplicaciones C++ en clientes OS/2 contra DB2/2: y de aquí a la negación, todo.

¿Referencias?

• VisualAge C++ for OS/2 versión 3, documentación de producto.
• Object-Oriented Development Environment, Nicholas Petreley, InfoWorld, 17(19), 8-5-1995.
• VisualAge C++ Visual Application Builder, Dale R. Nilsson, The Developer Connection News, volumen 9, 1995.
• Not just a Pretty Interface, Peter Coffee, PC Week, 24-07-1995.
• IBM’s VisualAge for C++ for OS/2 delivers Power Tools, Nancy Nicolaisen, Object Magazine, 5(6), Octubre 1995.

[1] Dado que se trata de una herramienta de alto rendimiento, me parece ridículo hablar de condiciones físicas mínimas o “umbral de instalación”

[2] SOM/DSOM (Distributed SOM) es la implementación IBM del ORB de CORBA.

[3] Al lector que quiera hacer cábalas le resultará interesante saber que, por ejemplo, el aclamado proyecto Taligent (Apple, IBM y HP) se ha esfumado de la noche al día: Taligent se ha convertido en una división interna de IBM. Oh, la constancia no es sello de las empresas de informática.

[4] El lector precavido deberá desconfiar sistemáticamente de la nota “basado en el borrador del estándar C++” que aparece en muchos compiladores C++, pues cada año se generan varios borradores: hay que preguntar siempre la fecha.

La frontera de lo deseable para trabajo en grupo se sitúa, a mi gusto, a partir del producto ENVY/Developer que tan bien conocen los programadores de Smalltalk.

[5] Borland C++ 5.0 incorpora, por ejemplo, la implementación completa de STL.

[6] Es un calco en más sentidos de los que el lector pudiera pensar. En contrapartida el código resultante del Visual Builder C++ no es (ni será, según IBM) compatible con el de Smalltalk.

[7] Si el lector desea más detalles sobre cómo el Visual Builder instrumenta la construcción visual de aplicaciones, debería echarle un vistazo a mi artículo “Programación Visual Orientada-a-Objetos”, RPP, noviembre-95.