|
|
Este no es un problema de cómputo, sino humano. Las agilidad de un negocio impide el mantener un modelo o conocimiento de las "reglas del negocio" en un lugar legible y centralizado. Si usted centraliza y documenta todos los procedimientos perfectamente, su negocio tiende a volverse rígido. Cuántas veces hemos oido "lo haría por usted, pero la computadora no me deja". Pero al mismo tiempo, el hacer sistemas flexibles que al mismo tiempo satisfagan las necesidades del usuario es mucho muy dificil sin un conocimiento claro de las reglas.
Muchas veces tenemos que hacer tremendos malabares para implementar exactamente lo que el usuario requiere. Aún con la mejor documentación y requerimientos, siempre acabamos en un ir y venir con los usuarios relevantes para implementar ciertos cálculos o procedimientos que no son claros para nadie más que para uno o dos usuarios en específico.
Con el correr de los años, los sistemas de cómputo se volvieron no sólamente la herramienta de todos los días, sino el único repositorio actualizado de todo el conocimiento acerca de cómo un negocio funciona. El problema es que este conocimiento está expresado en COBOL, Pascal, Java, C++, SQL y muchos otros lenguajes que la gente común y corriente no entiende, y algunas reglas muy importantes se encuentran dentro de ciclos "for-next" y "do-while".
Al darse cuenta de esto, y tomando en cuenta el hecho de que la orientación a objetos puede reflejar más fielmente la realidad, varios científicos de cómputo y eruditos decidieron que si pudieramos diseñar sistemas de cómputo utilizando modelos del mundo real (objetos que representen sus contrapartes en el mundo físico), y aplicaramos a esos modelos procedimientos y acciones relativas a otros objetos, podríamos lograr:
Un objeto de negocios es una representación virtual (ya sea en papel o en código) de un objeto en el mundo real, con especificaciones de todas sus interacciones con otros objetos.
El hecho de que tanta gente proporciona su conocimiento durante el diseño de un sistema es altamente significativo. Bajo un paradigma de objetos de negocios el diseño de sistemas es no sólo para crear una base de datos y un par de ejecutables, sino una oportunidad excelente para expresar y evaluar la manera en que funciona el mundo a nuestro alrededor (en lo que se refiere a nuestra actividad diaria dentro de la empresa, claro está).
Los objetos de negocios se describen en papel utilizando una notación de modelaje llamada UML (Unified Modeling Language) (TODO: Add Link).
Es muy importante tomar en cuenta de que la primera vez que realizamos un sistema de esta forma el diseño del sistema tomará mucho tiempo y muchas iteraciones y diagramación antes de escribir una sola línea de código o diseñar una sola pantalla o tabla.
Para tomar prestada una analogía de la notación UML, diseñar sistemas de objetos de negocios es un poco como escribir una obra de teatro. El escritor comienza por definir Actores (objetos), especificando su naturaleza, historia (razon de ser) y sus interacciones con otros Actores. Al hablar con los expertos que utilizan estos "actores" una y otra vez descubrimos más interacciones que reflejan más actores que a su vez interactúan con otros actores, nuevos o existentes.
Al final lo que tenemos es un modelo muy exacto de como funciona el negocio, pero en papel. Una vez hecho esto, podemos comenzar a definir bases de datos para guardar las características de los diferentes actores, código que representa los actores y todas sus interacciones, y pantallas (vestuario y coreografía) para llenar las características de los actores, con botones y eventos para activar sus acciones.
Cuando crece su empresa, o la cantidad de computadoras que usted maneja, el mantener todos los clientes configurados correctamente y con la más nueva versión de su programa instalado puede resultar complicado.
Supongamos que su programa mantiene e imprime facturas para sus clientes. El aparato fiscal de su país acaba de bajar los impuestos de ventas (jajajaja), y además ahora se calculan de manera diferente dependiendo del tipo de producto. Si usted tiene que reinstalar el programa en 50 tiendas simplemente porque el impuesto ha bajado, tendrá el riesgo de que algunas de las tiendas calcularán los impuestos de manera incorrecta hasta que usted instale el programa en todas las tiendas.
Tal vez usted dirá: "Bueno, incluso si esto es cierto, puedo poner una tabla centralizada con el porcentaje de impuestos". Si bien esto es cierto, ¿qué hará cuando lo que cambia es la manera de calcular? Esto ocurre muy seguido en el cálculo de impuestos en general en todos los países. Es muy dificil escribir un programa para interpretar fórmulas en una base de datos, especialmente cuando estas fórmulas pueden ser muy complicadas, con procedimientos, diferentes casos y repeticiones.
El paradigma de objeto de negocios es muy útil, pero nos ocasiona muchos problemas que Delphi ya había solucionado en cuanto a la programación de base de datos. El diseño de los objetos de negocios en sí totalmente ignora el concepto del DataSet, y con ello, los controles data-aware. Esto quiere decir que, en una implementación "pura" de un objeto de negocios, usted deberá de 1) utilizar controles normales y escribir una gran cantidad de código de infraestructura, o 2) crear su propio descendiente de TDataSet que funcione con cada uno de sus objetos de negocios.
Esto es un problema, especialmente cuando nos ponemos a pensar que tanto COM como CORBA son traducidos a llamadas locales en tiempo de compilación; lo cual quiere decir que es imposible convertir una interfase de objetos de negocio a un TDataSet sin tomar en cuenta la interfase de objeto de negocio en específico.
La tecnología MIDAS le permite exportar e importar DataSets a través de COM o CORBA (incluyendo constraints, reglas del negocio y otras ventajas), lo cual le dá casi todas las ventajas de los objetos de negocios sin tener que sufrir sus desventajas. Por supuesto, esto sólo funciona si tanto sus clientes como sus servidores utilizan tecnología MIDAS (que se encuentra disponible para Java, C++ Builder y Delphi).
Nota: Esta tecnología definitivamente no es para los puristas. El no exportar una interfase con Getters y Setters es casi un Tabú en UML, y le será dificil reconciliar un modelo UML con IDL generado con MIDAS. Uste deberá tomar una decisión basada en sus necesidades de purismo vs. tiempo de desarrollo. Tal como algunas personas utilizan herramientas RAD únicamente para hacer prototipos, tal vez usted querrá sólamente hacer prototipos con MIDAS y exportar interfases "reales" una vez que tiene un prototipo que los usuarios acepten.
He puesto la sección de MIDAS antes que las secciones de DCOM y CORBA intencionalmente porque usted no necesariamente debe saber de interfases para comenzar a utilizar MIDAS. Esto no quiere decir que el aprender interfases no le sea útil, sino que usted puede hacer programas pequeños y medianos con MIDAS y exportarlos como objetos CORBA o DCOM sin aprender nada de estas tecnologías, gracias a los Wizards de Delphi.
