Herramientas de desarrollo de aplicaciones

Si se toman unos cuantos usuarios preocupados y con problemas, se añade una herramienta de desarrollo rápido cliente/servidor, y unos pocos desarrolladores de aplicaciones con conocimientos actualizados, y se agita la mezcla, ¿qué se obtiene? Un sistema "heredado" instantáneo: difícil de ampliar, costoso de mantener y problemas para explicar a los usuarios por qué el sistema no envejece bien.

La inmensa popularidad de herramientas de desarrollo como VisualBasic de Microsoft y PowerBuilder de Powersoft ha dado lugar a que los sistemas cliente/servidor parezcan más fáciles de construir de lo que son en realidad. Mientras que los sistemas sencillos y orientados a pequeños grupos de trabajo están siendo considerados como un éxito, a estas herramientas y equipos se les está encargando la tarea de crear aplicaciones más grandes y más complejas. Y no son capaces de hacerle frente.

Se ha dado por hecho que estas herramientas cliente/servidor de nivel bajo son capaces de crear sistemas con una "unidad mínima de esfuerzo": tres personas durante tres meses o cualquier otra combinación hasta aproximadamente nueve personas/mes. Una aplicación que necesite un mayor esfuerzo es seguramente demasiado grande para ser construida adecuadamente mediante herramientas de primera generación.

En el problema intervienen más factores que el simple número de usuarios que van a manejar el sistema. También intervienen la escala, la complejidad y la solidez. En la cuestión de la escala se incluye el tamaño de la aplicación resultante (el número de pantallas, formularios, tablas de base de datos, sistemas incluidos, etc.), la cuantía del esfuerzo de desarrollo (el número de desarrolladores, comprobadores, plataformas, entornos operativos, etc.) y la cuantía del esfuerzo de gestión (número de versiones a utilizar, control de la seguridad y los accesos, etc.)

Considérese por ejemplo una aplicación comercial crítica con miles de usuarios, cientos de formularios e informes, que requirió decenas de desarrolladores, accede a varios sistemas de base de datos en diversas plataformas, necesita un rendimiento muy elevado y debe funcionar de manera continua. Desarrollar una aplicación así no es tarea para herramientas de primera generación.

Libertad frente a limitaciones en el diseño

Un desarrollo efectivo de aplicaciones cliente/servidor deberá estar basado en un principio de "divide y vencerás". La flexibilidad al dividir la lógica de aplicación es la clave de la utilidad y eficacia de la herramienta.

La mayor parte de los primeros sistemas cliente/servidor (conocidos también como sistemas de primera generación) podrían ser considerados también como sistemas de "dos niveles". En esta arquitectura, la mayor parte de la lógica de aplicación -interface de usuario, reglas comerciales y cálculos de aplicación- está situada en el cliente, y la base de datos se mantiene únicamente como un servidor.

Aunque este esquema permite un fácil acceso a los datos y a la potencia de proceso en la estación de trabajo del usuario, la solución puede ser "demasiado buena". El problema principal es el que se conoce como de clientes "gordos", ya que los requerimientos de la aplicación fuerzan al sistema cliente hacia sistemas desktop más grandes y más costosos. Los sistemas cliente con deficiencias de potencia hacen más lento el rendimiento de la aplicación.

El siguiente nivel de herramientas de aplicación ofrece un grado o nivel adicional de particionamiento de aplicaciones, y puede ser considerado como de "dos niveles y medio". Las bases de datos relacionales modernas pueden almacenar porciones de código, utilizando lenguaje SQL o extensiones de éste, en forma de "procedimientos almacenados" o "triggers". Estos procedimientos almacenados pueden contener reglas a nivel de aplicación (por ejemplo, cálculos de cantidades estándar, como el "margen neto"), alguna validación de los datos de entrada que necesite más que cláusulas "picture", y algún proceso en cascada.

Sin embargo, esta arquitectura está siendo relegada rápidamente para ser utilizada sólo en las aplicaciones más sencillas, debido a sus limitaciones. Por ejemplo, el lenguaje de procedimientos almacenados no es estándar, y puede ser incapaz de expresar un algoritmo deseado; los procedimientos almacenados están limitados a una base de datos; y la arquitectura no ofrece soporte para gestión "runtime" de las aplicaciones.

El nivel más alto de particionamiento de aplicaciones es el que se conoce como de "tres niveles". En este nivel, las herramientas de desarrollo permiten que una parte del proceso -generalmente, la parte de presentación e interacción con el usuario- resida en sistemas cliente, mientras que la lógica comercial y los algoritmos de aplicación se sitúan en un servidor o en varios servidores, y la base de datos reside posiblemente en otros servidores.

Esta arquitectura permite una utilización óptima de los recursos de servidor, así como un control completo en la gestión. Además, hace posible un diseño óptimo, de forma que, por ejemplo, la red no resulta sobrecargada, como sucede con frecuencia en aplicaciones de dos o de dos y medio niveles.

Una herramienta de desarrollo para aplicaciones de gran escala debe ser capaz de crear aplicaciones de tres niveles completas. Hay que precaverse contra las herramientas que ofrecen "particionamiento de aplicaciones" si todo lo que esto implica es la capacidad de crear procedimientos almacenados, es decir, sistemas de dos y medio niveles.

El segundo grupo de cuestiones se refiere a la diversidad de entornos en cualquier empresa actual. Por ejemplo, otra capacidad de las aplicaciones a considerar es el interface de usuario permitido. Aunque la mayor parte de las aplicaciones cliente/servidor están dirigidas al uso de interfaces gráficos, puede haber usuarios que requieran terminales de caracteres, y algunas herramientas de desarrollo permiten generar ambos tipos de interfaces en base a la misma definición de aplicación.

La cuestión multiplataforma es más importante para una aplicación de nivel de empresa que para una aplicación de grupo de trabajo. Los clientes y los servidores potenciales pueden ser más diversos, y es menos probable que estén bajo el control de la organización de sistemas de información. Las plataformas cliente resultan problemáticas, porque algunas herramientas de desarrollo no pueden manejar todas las versiones de Windows. Será necesario por lo tanto evaluar las posibles plataformas de destino antes de elegir la herramienta de desarrollo.

De forma similar, es importante también la cuestión de si la aplicación debe ser independiente de base de datos. Algunas herramientas dejan ligado al usuario a la base de datos del vendedor, o quizás prometen acceso a través de gateways o de conectividad ODBC (Open Database Connectivity), mientras que otras ofrecen drivers nativos para todos los principales sistemas de base de datos y tienen acceso ODBC para el resto.

Para una decisión a nivel de empresa deberá considerarse no sólo la aplicación que se está creando, sino también la necesidad de futuras aplicaciones y los sistemas de base de datos de la empresa que podrá ser necesario conectar a esa aplicación en el futuro. Sin embargo, una herramienta independiente de base de datos puede no utilizar todas las capacidades -o todas las funciones y características más recientes- de una base de datos específica.

Sin problemas de escasez

La amplitud y cuantía de la capacidad es uno de los primeros elementos a considerar por el departamento de sistemas de información al seleccionar una herramienta de desarrollo a nivel de empresa.

El entorno integrado ADE (Application Development Environment) y base de datos relacional de la firma Progress Software cumplieron este requerimiento para la empresa Bay State Gas, que quería un